Re: yield() in i2c non-happy paths hits BUG under -rt patch

On Thu, 19 Nov 2009, Jean Delvare wrote:

quoted

That still does not explain why yield() is necessary _between_ the
transaction attempts.

It is not _necessary_. We are just trying to be fair to other kernel
threads, because bit-banging is expensive and this is the only case
where we know we can tolerate a delay.

Just to clarify things... does (or did) yield() have anything to do
with CONFIG_PREEMPT_VOLUNTARY?

No.
 

quoted

That code is fully preemptible, otherwise you could not call
yield().

How does one know what code is preemtible and what code is not? The
rest of the i2c-algo-bit code should definitely _not_ be preemtible, as
it is highly timing sensitive.

Code is preemptible when preempt_count() == 0 and interrupts are
enabled. spin_lock() implicitely disables preemption.
 

quoted

And as I said before nobody even noticed that the yield()
default implementation was changed to a NOOP by default in the
scheduler.

Well, I guess only people monitoring system latency would notice, as
this is the only thing yield() was supposed to help with in the first
place.

You say "NOOP by default", does this imply there is a way to change
this?

There is a sysctl: sysctl_sched_compat_yield
 

Was yield() turned into NOOP by design, or was it a bug?

By design. The semantics of yield and the fairness approach of CFS are
not really working well together. Also yield() for SCHED_OTHER is not
really specified.

Thanks,

	tglx