* Steven Rostedt [off-list ref] wrote:

On Fri, 2011-03-25 at 16:50 +0300, Andrey Kuzmin wrote:

quoted

On Fri, Mar 25, 2011 at 4:12 PM, Steven Rostedt [off-list ref] wrote:

quoted

On Fri, 2011-03-25 at 14:13 +0300, Andrey Kuzmin wrote:

quoted

Turning try_lock into indefinitely spinning one breaks its semantics,
so deadlock is to be expected. But what's wrong in this scenario if
try_lock spins a bit before giving up?

Because that will cause this scenario to spin that "little longer"
always, and introduce latencies that did not exist before. Either the
solution does not break this scenario, or it should not go in.

Broken semantics and extra latency are two separate issues. If the
former is fixed, the latter is easily handled by introducing new
mutex_trylock_spin call that lets one either stick to existing
behavior (try/fail) or choose a new one where latency penalty is
justified by locking patterns.

For those wanting a more RT deterministic OS, I will argue against
latency penalties.

Later mails from Tejun suggest that the benchmark results are varied, and that 
it's not a clear win after all.

It's possible that if useless spinning is introduced then that might explain 
such workload variations. I.e. it's not really 'latencies' but 'unnecessary 
overhead spent spinning' - and also 'extra non-deterministic noise' - none of 
which help consistent performance.

Thanks,

	Ingo