Re: [ANNOUNCE] 3.2.9-rt17

On Thu, 2012-03-08 at 16:44 -0500, Steven Rostedt wrote:

On Thu, 2012-03-08 at 22:37 +0100, Peter Zijlstra wrote:

quoted

quoted

Now when the original task releases the lock again, the other task can
take it just like it does on mainline.

Now interleave it with a third task of even higher priority that puts
the spinner to sleep.

So? It will eventually have to allow the task to run. Adding a "third
higher priority" task can cause problems in any other part of the -rt
kernel.

We don't need to worry about priority inversion. If the higher task
blocks on the original task, it will boost its priority (even if it does
the adaptive spin) which will again boost the task that it preempted.

Now we may need to add a sched_yield() in the adaptive spin to let the
other task run.

That's not what I mean,..

task-A (cpu0)	task-B (cpu1)		task-C (cpu1)

		lock ->d_lock
lock ->i_lock
lock ->d_lock
			<-------------- preempts B
		trylock ->i_lock


While is is perfectly normal, the result is that A stops spinning and
goes to sleep. Now B continues and loops ad infinitum because it keeps
getting ->d_lock before A because its cache hot on cpu1 and waking A
takes a while etc..

No progress guarantee -> fail.

Test-and-set spinlocks have unbounded latency and we've hit pure
starvation cases in mainline. In fact it was so bad mainline had to grow
ticket locks to cope -- we don't want to rely on anything like this in
RT.