On Wed, 2006-05-24 at 11:24 +1000, David Chinner wrote:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114491661527656&w=2
>
> shrink_dcache_sb() becomes a severe bottleneck when the unused dentry
> list becomes long and mounts and unmounts occur frequently on the
> machine.
how does a per SB list deal with umounts that occur frequently? I
suppose it means destroying just your list...
> I've attempted to make reclaim fair by keeping track of the last superblock
> we pruned, and starting from the next on in the list each time.
how fair is this in the light of a non-equal sizes? say you have a 4Gb
fs and a 1Tb list. Will your approach result in trying to prune 1000
from the 4Gb, then 1000 from the 1Tb, then 1000 from the 4Gb etc ?
while that is fair in absolute terms, in relative terms it's highly not
fair to the small filesystem....
(I'm not sure there is ONE right answer here, well maybe by scaling the
count to the per fs count rather than to the total...)
this makes me wonder btw if we can do a per superblock slab for these
dentries, that may decrease fragmentation of slabs in combination with
your patch....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
