The inode unused list is currently a global LRU. This does not match the other global filesystem cache - the dentry cache - which uses per-superblock LRU lists. Hence we have related filesystem objec
The inode unused list is currently a global LRU. This does not match the other global filesystem cache - the dentry cache - which uses per-superblock LRU lists. Hence we have related filesystem objec
Is this an improvement I wonder? The dcache is using per sb lists because it specifically requires sb traversal. What allocation/reclaim really wants (for good scalability and NUMA characteristics) i
Right - I originally implemented the per-sb dentry lists for scalability purposes. i.e. to avoid monopolising the dentry_lock during unmount looking for dentries on a specific sb and hanging the syst
Right, that's why I wonder whether it is an improvement. It would be interesting to see some tests (showing at least parity). Right, it just makes it harder to do. By much harder, I did mostly mean t
I've done some testing showing parity. They've been along the lines of: - populate cache with 1m dentries + inodes - run 'time echo 2 > /proc/sys/vm/drop_caches' I've used different methods of popula
I guess the problem is that inode LRU cache isn't very useful as long as there are dentries in the way (which is most of the time, isn't it?). I think nfsd will exercise them better? Dont know of any
It's a shape that s_inode_lru is still protected by inode_lock. One day we're going to get in trouble over that lock. Migrating to a per-sb lock would be logical and might help. Did you look into thi
Yes, I have. Yes, it's possible. It's solving a different problem, so I figured it can be done in a different patch set. *nod* Sort of. The complexity is the stats are userspace visible, so they can'
It almost all goes away in my inode lock splitup patches. Inode lru and dirty lists were the last things protected by the global lock there. I am actually going to do per-zone lrus for these guys and