lkml.org 
[lkml]   [2010]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Inode Lock Scalability V4
    On Sun, Oct 17, 2010 at 01:55:33PM +1100, Nick Piggin wrote:
    > On Sun, Oct 17, 2010 at 01:47:59PM +1100, Dave Chinner wrote:
    > > On Sun, Oct 17, 2010 at 04:55:15AM +1100, Nick Piggin wrote:
    > > > On Sat, Oct 16, 2010 at 07:13:54PM +1100, Dave Chinner wrote:
    > > > > This patch set is just the basic inode_lock breakup patches plus a
    > > > > few more simple changes to the inode code. It stops short of
    > > > > introducing RCU inode freeing because those changes are not
    > > > > completely baked yet.
    > > >
    > > > It also doesn't contain per-zone locking and lrus, or scalability of
    > > > superblock list locking.
    > >
    > > Sure - that's all explained in the description of what the series
    > > actually contains later on.
    > >
    > > > And while the rcu-walk path walking is not fully baked, it has been
    > > > reviewed by Linus and is in pretty good shape. So I prefer to utilise
    > > > RCU locking here too, seeing as we know it will go in.
    > >
    > > I deliberately left out the RCU changes as we know that the version
    > > that is in your tree causes siginificant performance regressions for
    > > single threaded and some parallel workloads on small (<=8p)
    > > machines.
    >
    > The worst-case microbenchmark is not a "significant performance
    > regression". It is a worst case demonstration. With the parallel
    > workloads, are you referring to your postmark xfs workload? It was
    > actually due to lazy LRU, IIRC. I didn't think RCU overhead was
    > noticable there actually.
    >
    > Anyway, I've already gone over this couple of months ago when we
    > were discussing it. We know it could cause some small regressions,
    > if they are small it is considered acceptable and outweighed
    > greatly by fastpath speedup. And I have a design to do slab RCU
    > which can be used if regressions are large. Linus signed off on
    > this, in fact. Why weren't you debating it then?

    It goes to the heart of the locking model, and I think it is silly
    just to do this and then go and rewrite locking a release or two later
    when rcu is introduced. And change it again when you start listening
    to the people who want per-zone lrus.



    \
     
     \ /
      Last update: 2010-10-17 04:59    [W:0.023 / U:0.316 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site