lkml.org 
[lkml]   [2009]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject[patch 00/33] my current vfs scalability patch queue
    Hi,

    Had a bit of time to work on my vfs scalability patches. Since last time: made
    some bugfixes, scaled mntget/mntput with per-cpu counter and vfsmount brlock,
    and worked on inode cache scalability. This last one is the most interesting...
    with my last posting I had got as far as breaking the locks into constituent
    parts, but they remained mostly global locks.

    - I have now made per-bucket hash lock like the dcache (it still needs to be
    made into bitlocks to avoid any bloat, but using spinlocks for now helps eg
    with lockdep).

    - Made the inode unused lru list into a lazy list like the dcache. This reduces
    acquisitions of the lru/writeback list lock.

    - Made inode rcu freed. This can enable further optimisations. But it is quite
    a big change on its own worth noting.

    - RCU freed inode enables the sb_inode_list_lock to be avoided in list walkers,
    and therefore allows it to nest within i_lock. This significantly simplifies
    the locking and reduces acquisitions of sb_inode_list_lock.

    Some remaining obvious issues:

    - Not all filesystems are completely audited, especially when it comes to
    looking at inode/dentry callbacks now done with locks lifted.

    - Global dcache_lru lock. This can be made per-zone which will improve
    scalability and enable more efficient targetted reclaim. Needs some of
    my old per-zone reclaim shrinker patches.

    - inode sb list lock is limiting global rate of inode creation, inode wb
    list lock is limiting global rate of inode dirtying and writeback.

    - Inode writeback list lock tied with inode lru list lock (they use the same
    list head). Could turn them into 2 locks. Then the lru lock can be made
    per-zone. The writeback lock I will wait on Jens' writeback work.

    - sb_inode_list_lock can be made per-sb. This is a reasonable step, but not
    good for single-sb scalability. Could perhaps add some per-cpu magazines or
    laziness to reduce some of this locking. Most walkers of this list are
    slowpaths, so it could be split into percpu lists or something.

    - inode lru lock could also be made per-zone.

    - dentries and inodes are now rcu freed, some (most?) nested trylock loops
    could be removed in favour of taking the correct lock order and then
    re-checking that things haven't changed.

    The reason I have had to go on with more changes to locking rather than trying
    to get things merged is because it has been difficult to show improvements in
    some cases, like for example in the inode cache lock breaking, it first
    resulted in actually more global locks for different things so scalability
    could be worse in some cases when multiple global locks need to be taken.

    But it is now getting to the point where I will need to get some agreement with
    the approach.




    \
     
     \ /
      Last update: 2009-09-04 09:27    [W:4.424 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site