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

Andrea Arcangeli (andrea@e-mind.com)
Thu, 11 Feb 1999 11:20:19 +0100 (CET)


On Thu, 11 Feb 1999, Alexander Viro wrote:

>sense. For separately allocated pieces - no way. Inodes are *way* too fat
>right now. IMHO we should have two different beasts - VFS inode (generic

How much too fat? I thought it wasn't an issue. I thought it could be an
issue on a machine with 4Mbyte of phys RAM but I thought it was not an
issue on rasonable new hardware.

>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

I noticed that was a pain to call from fs.h any `extern inline' functions
implemented in swap.h ;)

>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.

Agreed, better to do the work in shrink_dcache(). Once you shrunk the
dcache you can free also the inodes that was attached to the freed
dentries (if I understand right how the dcache works).

Andrea Arcangeli

-
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/