KS2009: Realtime preemption

Thomas Gleixner led a session on the realtime preemption tree. The primary purpose of this discussion was to reach a conclusion on the naming of locking primitives in the kernel. Merging the realtime tree requires splitting the current spinlock_t type in two - a few "core spinlocks" which retain spinlock behavior even in realtime kernels, and the "sleeping spinlocks" which behave very differently in those kernels. As was discussed at the realtime preemption mini-summit, the original plan was to rename just the core locks, for the simple reason that it's a much smaller patch. That, however, leaves the kernel with a "spinlock" type which might not be a spinlock; that naming created confusion at the mini-summit and was seen as being confusing for the rest of the development community as well. So the idea of changing spinlock_t to something like lock_t was taken to the kernel summit.

The question got a quick answer: Linus has generally refrained from making outright decrees at this summit, but he did so here. He's very much against changing the name of spinlocks; it would be a huge patch, causing a lot of readjustment and pain, and he doesn't think it's worth it. Besides, Linus asserted, these locks remain spinlocks in all the ways that matter: code holding them still cannot schedule. Other parts of the kernel didn't change names when the realtime tree changed their function; code which looks like it is disabling interrupts may not be, for example. The same thing can be done here.

And, according to Linus, the realtime people are crazy, so they can be left to deal with the weird stuff.

There was some discussion, but few people were willing to argue against Linus on this one. So the decision appears to be made: spinlock_t will not change. Instead, the developers looked like they were heading into a full-on debate on the proper name for "core spinlocks" before being redirected to something more useful.

Removal of the big kernel lock (BKL) was discussed for a bit. Perhaps the biggest remaining problem is in the TTY layer, where few developers dare to tread. The BKL is still needed there, but nobody is quite sure what it is protecting. Some (more) effort will be needed to clean that code up. Beyond that, much of the remaining BKL-removal work involves going into ancient drivers, deciding what needs to be done about locking, and clean them up. But there is a real suspicion that many of those drivers are not really in active use anymore, so it's not clear that it is worth the effort to fix them. There was talk of introducing a CONFIG_BKL configuration option which would be required to enable those drivers; that option could then be made to conflict with realtime operation.

In general, the realtime preemption code is getting close to being ready to merge into the mainline. There are a few remaining issues, though. One of those is per-CPU data. The kernel makes extensive use of per-CPU variables; they can be accessed quickly, without locking, and without cache contention. Use of per-CPU data requires disabling preemption, though, which is exactly what the realtime developers are trying to get away from. The current realtime tree deals with the problem by protecting per-CPU data with (sleeping) locks, but that solution is seen as too ugly to push into the mainline. So something else will have to be done there, but what that "something else" will be is not yet clear.

Significantly, nobody questioned the overall value of merging the realtime code into the mainline. Instead, some of the other discussions have made it clear that there are a lot of users for this functionality and that it is needed. So this merger will eventually happen, but your editor has learned better than to try to predict when.

Next: Generic architecture support

Index entries for this article
Kernel	Realtime

---

to post comments

KS2009: Realtime preemption

Posted Oct 21, 2009 6:29 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

I like the idea of CONFIG_BKL being required for older drivers and not trying too hard to fix them (especially since the people doing the changes probably don't have the hardware to test with)

KS2009: Realtime preemption

Posted Oct 29, 2009 20:15 UTC (Thu) by joib (subscriber, #8541) [Link]

Then again, due to all the subtleness in the BKL (e.g. http://lwn.net/Articles/283066/ ), it wouldn't surprise me if many of these drivers would then be broken anyway, since they could depend on some other piece of code acquiring the BKL at some suitable point.

Anyway, I suppose that's the price of progress. One can at least hope that in the longer term, the elimination of the BKL will not only improve latencies and corner-case scalability, but also quality as the replacement locking will be better designed and understood.

KS2009: Realtime preemption

Posted Oct 23, 2009 22:27 UTC (Fri) by dvhart (guest, #19636) [Link] (2 responses)

"Significantly, nobody questioned the overall value of merging the realtime code into the mainline."

Did this include sleeping spinlocks? My understanding has been that these are the ugly duckling of the PREEMPT_RT tree that the rest of the kernel developers would rather not see in mainline.

Ugly duckling?

Posted Oct 28, 2009 10:29 UTC (Wed) by dion (guest, #2764) [Link]

The ugly duckling was a swan, not a duck and it was ostracized for being ugly when viewed by the standards of ducklings.

... so are you saying that the "sleeping spinlocks" feature is the most wonderful change of all the RT changes and that people simply doesn't understand it?

KS2009: Realtime preemption

Posted Oct 29, 2009 20:35 UTC (Thu) by joib (subscriber, #8541) [Link]

AFAICS the "adaptive mutexes" patch went into 2.6.30 ( http://lwn.net/Articles/325921/ ). Well, sleeping spinlock, spinning mutex, adaptive mutex, or whatever you want to call it.

Or did you mean the part of the -rt patch that automagically turns most spinlocks into such adaptive mutexes (w/ PI)? Yeah, that might be more difficult to get into mainline?