Messages in this thread | | | Date | Wed, 7 Mar 2007 16:43:44 -0800 | Subject | Re: [patch 2/6 -rt] powerpc 2.6.20-rt8: to convert spinlocks to raw ones. | From | Bill Huey (hui) <> |
| |
On Thu, Mar 08, 2007 at 08:30:43AM +1100, Paul Mackerras wrote: > Sergei Shtylyov writes: > > > I've floowed up to my patch with such explanation. In the context of an-rt > > patch itself, it was just too clear, hence I didn't go into explanations in > > the patch itself. :-) > > Well, it might be clear, to you, now, with the context in your head. > But if such a patch is to go into a git tree, and somebody comes along > in 3 years time and wants to know exactly why you made that change > (and maybe that somebody is you :), then they will need more detail - > such as how you came to the conclusion that those locks and no others > needed to be changed, for instance. > > At least give some of the reasoning behind your choice of which locks > to convert, so that in future, if the patch turns out to have > introduced a bug somehow, the person debugging it can either identify > that there was a flaw in your logic, or else understand something that > you have seen that they missed.
Paul,
It has to do with how locking is done in the -rt patch itself. It's probably before the time of general maintainers since the -rt patch hasn't been fully merged, but I agree a document needs to be written outlining what needs to be changed to spinlocks and what locks can be emulated with the rtmutex.c/rt.c logic. There aren't that many people that know specifically unless they've tried to map out chunks of the Linux kernel for this purpose in the first place. I only know because of my own parallel effort to get the kernel to be preemptive (the old mmLinux project that I abandoned for Ingo's stuff).
Generally, things that run within interrupt contexts need to be spinlocks. The interrupt controller is one of those things obviously, the timer interrupt for practical reasons such as performance and other places so that locking is outside of direct control and scope of the scheduler. Of course the scheduler's runqueues needs to be spinlocked for the reasons above otherwise your system is stuck with a kind chicken and the egg problem interacting with the scheduler.
The places that need to be reverted to raw spinlocks are generally either acquired by function calls that allocate the spinlock at a terminal of the kernel's lock graph or isolated from other callers completely (parts of the timer for logic for instance). It's all about the collision of various lock (preemptive and non-preemptive) subtrees and how to avoid scheduling within atomic violations that lead to deadlocks. The -rt patch gets arbitrary preemption abilities by shrinking the non-preemptive sub-tree bit to the bare essentials of what will let a system to run yet still preserve all of the expected locking semantics of a critical section.
Otherwise everything by default is backed by a blocking rtmutex identity to provide for correct preemptivity behavior within critical sections. That is why these reverts are needed to restore the mathematical correctness of the kernel's locking structures.
I hope this is helpful.
bill
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |