Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 11 Feb 1999 04:57:07 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [patch] real fix [Re: [patch] fixed 2.2.1 inode-leakage due bogus design of the free_inodes algorithm |
| |
On Thu, 11 Feb 1999, Andrea Arcangeli wrote:
> On Wed, 10 Feb 1999, Alexander Viro wrote: > > >resonable place being ->clear_inode() method. And it's called by > >fs/inode.c::clear_inode(). Called by fs/inode.c::dispose_list(). Called > >by fs/inode.c::free_inodes(). Called by fs/inode.c::free_inode_memory(). > >See the path now? > > Yes thanks ;) > > > Again, it doesn't free inode memory per se. But for some inodes it > >informs filesystems that they should free their internal data associated > >with said inodes. > > I think we should consider such memory as statically allocated and > decrease inode-max if we are worried by the too much memory used for inode > purposes. The inode pool act as fixed-size cache so the right reason for > shrink it is to generate new inodes not to free memory. If you have low > memory better that you use a smaller inode pool in first place.
Ahem... I'm not sure that I've parsed it right. For inode pool it may make sense. For separately allocated pieces - no way. Inodes are *way* too fat right now. IMHO we should have two different beasts - VFS inode (generic part) and fs-specific one (current ->u.foo_inode_info). Having a God-awful union doesn't scale. Ever tried to look how much does fs.h suck in when it expands (gcc -E|wc -l)? And don't get me started on the fact that change in ufs_fs_i.h means recompiling half of the tree. It's severely wrong. I think that we should move to keeping fs-specific parts separate. And free_inode_memory() looks like a reasonable place for asking icache to look for inodes it can take away from filesystems. Maybe it should be called by shrink_dcache() and be invisible for VM - after all, it's VFS business what to trim and what kind of balance should be kept between dcache, icache and fs-specific parts. Cheers, Al
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |