Re: [patch] real fix [Re: [patch] fixed 2.2.1 inode-leakage due bogus design of the free_inodes algo

Alexander Viro (viro@math.psu.edu)
Thu, 11 Feb 1999 04:57:07 -0500 (EST)


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/