Messages in this thread | | | Date | Wed, 18 Nov 2009 11:52:46 +0100 | From | Nick Piggin <> | Subject | Re: -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.
| |