Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+1\/5\]\s+inode\:\s+Make\s+unused\s+inode\s+LRU\s+per\s+superblock\s*$/: 10 ]

Total 10 documents matching your query.

1. [PATCH 1/5] inode: Make unused inode LRU per superblock (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 14 May 2010 17:24:19 +1000
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
/archives/xfs/2010-05/msg00157.html (18,504 bytes)

2. [PATCH 1/5] inode: Make unused inode LRU per superblock (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 25 May 2010 18:53:04 +1000
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
/archives/xfs/2010-05/msg00359.html (18,571 bytes)

3. Re: [PATCH 1/5] inode: Make unused inode LRU per superblock (score: 1)
Author: Nick Piggin <npiggin@xxxxxxx>
Date: Thu, 27 May 2010 02:17:33 +1000
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
/archives/xfs/2010-05/msg00400.html (9,535 bytes)

4. Re: [PATCH 1/5] inode: Make unused inode LRU per superblock (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 27 May 2010 09:01:29 +1000
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
/archives/xfs/2010-05/msg00404.html (11,671 bytes)

5. Re: [PATCH 1/5] inode: Make unused inode LRU per superblock (score: 1)
Author: Nick Piggin <npiggin@xxxxxxx>
Date: Thu, 27 May 2010 12:04:45 +1000
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
/archives/xfs/2010-05/msg00410.html (13,491 bytes)

6. Re: [PATCH 1/5] inode: Make unused inode LRU per superblock (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 27 May 2010 14:02:10 +1000
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
/archives/xfs/2010-05/msg00413.html (15,180 bytes)

7. Re: [PATCH 1/5] inode: Make unused inode LRU per superblock (score: 1)
Author: Nick Piggin <npiggin@xxxxxxx>
Date: Thu, 27 May 2010 14:23:32 +1000
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
/archives/xfs/2010-05/msg00415.html (15,569 bytes)

8. Re: [PATCH 1/5] inode: Make unused inode LRU per superblock (score: 1)
Author: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 27 May 2010 13:32:30 -0700
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
/archives/xfs/2010-05/msg00442.html (12,326 bytes)

9. Re: [PATCH 1/5] inode: Make unused inode LRU per superblock (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 28 May 2010 08:54:18 +1000
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'
/archives/xfs/2010-05/msg00449.html (13,870 bytes)

10. Re: [PATCH 1/5] inode: Make unused inode LRU per superblock (score: 1)
Author: Nick Piggin <npiggin@xxxxxxx>
Date: Fri, 28 May 2010 20:07:19 +1000
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
/archives/xfs/2010-05/msg00464.html (13,009 bytes)


This search system is powered by Namazu