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