Messages in this thread | | | Date | Thu, 11 Feb 1999 11:20:19 +0100 (CET) | From | Andrea Arcangeli <> | 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, 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/
| |