[lkml]   [2009]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: -rt dbench scalabiltiy issue
    On Wed, Nov 18, 2009 at 11:19:14AM +0100, Thomas Gleixner wrote:
    > Nick,
    > On Wed, 18 Nov 2009, Nick Piggin wrote:
    > > > So yes, on -rt, the overhead from lock contention is way way worse then
    > > > any extra atomic ops. :)
    > >
    > > How about overhead for an uncontended lock? Ie. is the problem caused
    > > because lock *contention* issues are magnified on -rt, or is it
    > > because uncontended lock overheads are higher? Detailed callgraph
    > > profiles and lockstat of +/-atomic case would be very interesting.
    > In the uncontended case we have the overhead of calling might_sleep()
    > before we acquire the lock with cmpxchg(). The uncontended unlock is a
    > cmpxchg() as well.

    OK well then you don't reduce atomic ops in the lookup/dput fastpaths
    by protecting d_count with d_lock, so single threaded performance should
    not hurt by using atomic_t here.

    I'll keep this in mind. As I said, I still need to do some more work on
    the fast path lookup and other single threaded performance. In the worst
    case that mainline really doesn't like atomic_t there it probably isn't
    hard to make some small wrappers for -rt.

    > I don't think that this is significant overhead and we see real lock
    > contention issues magnified by at least an order of magnitude.

    Yeah I'm sure you're right. I'm just interested where it is coming from
    in -rt.

     \ /
      Last update: 2009-11-18 11:55    [W:0.020 / U:4.536 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site