David Miller wrote:

From: Vernon Mauery <redacted>
Date: Wed, 18 Mar 2009 14:10:33 -0700

  

quoted

David Miller wrote:
    

quoted

From: Andi Kleen <redacted>
Date: Wed, 18 Mar 2009 21:54:37 +0100

      

quoted

But then again I'm not sure it's  worth it if the problem only
happens in out of tree RT.
        

The list of problems that only show up with the RT kernel seems to be
constantly increasing, but honestly is very surprising to me.
I don't understand why we even need to be concerned about this stuff
upstream, to be honest.
Please reproduce this in the vanilla kernel, then get back to us.
      

Huh? The numbers that I posted *were* from the vanilla kernel. I ran
the 2.6.29-rc8 kernel with lock_stat enabled.  The lock contention
happens on the same lock in both vanilla and -rt, it just happens
to be more pronounced in the -rt kernel because of the double context
switches that the sleeping spinlock/rt-mutexes introduce.
    

And the double context switches are probably also why less
natural batching and locality are achieved in the RT kernel.

Isn't that true?
  

Note that -rt doesnt typically context-switch under contention anymore
since we introduced adaptive-locks.  Also note that the contention
against the lock is still contention, regardless of whether you have -rt
or not.  Its just that the slow-path to handle the contended case for
-rt is more expensive than mainline.  However, once you have the
contention as stated, you have already lost.

We have observed the posters findings ourselves in both mainline and
-rt.  I.e. That lock doesnt scale very well once you have more than a
handful of cores.  It's certainly a great area to look at for improving
the overall stack, IMO, as I believe there is quite a bit of headroom
left to be recovered that is buried there.

Regards,
-Greg