Bill Huey (hui) writes: > 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.
Thanks; that's an interesting explanation. It misses the point of what I was saying to Sergei, though, which was *not* "I don't understand your patch", it was "if this patch goes into a git tree, someone coming along in 3 years time won't understand the patch." In other words I was ranting about the need for a decent description to accompany the patch itself, so it would go into the permanent record. Regards, Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/