lkml.org 
[lkml]   [1999]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.437 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site