On Wed, Mar 18, 2009 at 05:54:04PM -0400, Gregory Haskins (ghaskins@xxxxxxxxxx) wrote: > 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. Something tells me that you observer skb head lock contention because you stressed the network and anything else on that machine slacked in sleep. What if you will start IO stress, will __queue_lock contention have the same magnitude order? Or having as many processes as skbs each of which will race for the scheduler? Will run-queue lock show up in the stats? I believe the asnwer is yes for all the questions. You stressed one subsystem and it showed up in the statistics. -- Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
