David Miller wrote: > From: Vernon Mauery <vernux@xxxxxxxxxx> > Date: Wed, 18 Mar 2009 14:10:33 -0700 > > >> David Miller wrote: >> >>> From: Andi Kleen <andi@xxxxxxxxxxxxxx> >>> Date: Wed, 18 Mar 2009 21:54:37 +0100 >>> >>> >>>> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
