On Mon, Jun 19, 2006 at 09:54:22AM -0700, Christoph Lameter wrote:
> On Mon, 19 Jun 2006, Theodore Tso wrote:
>
> > What else remains to be done? There are a large number of fields in
> > struct inode which are never populated unless the inode is open, and
> > those should get moved into another structure which is populated only
> > when needed. There are a large number of inodes which are read into
> > memory only because stat(2) was called on them (thanks to things like
> > color ls, et. al).
>
> One could remove the reclaim list and use the slab lists of the slab
> allocator to scan through the inodes and reclaim them in such a way
> that would maximize the number of pages freed. I will post an RFC on that
> one later. This may reduce the complexity of inode reclaim.
That may very well be a good thing to do (although if it is too
aggressive we may end up reducing the utility of the dentry cache ---
your patch is going to try to free the dentries pinning inodes, right?
Otherwise it will probably not have much effect), but I think that's a
largely orthogonal issue. It will still be good to be able to cache
inodes (and dentries), but it would be desireable if we can do this in
less memory than it currently takes, and separating out those fields
which are only needed when the inode is opened, or when its pages are
cached in the page cache, would be a good way of minimizing the
footprint of inodes who only needs to have their stat(2) information
cached.
Regards,
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
