On Wed, 18 Nov 2009 21:36:48 +0100 (CET), Thomas Gleixner wrote:
On Wed, 18 Nov 2009, Jean Delvare wrote:
On Wed, 18 Nov 2009 17:28:53 +0100, Leon Woestenberg wrote:
On Wed, Nov 18, 2009 at 2:05 AM, Alan Cox a...@lxorguk.ukuu.org.uk
wrote:
Our timers are very efficient and some day
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.
if (need_resched())
schedule();
will make non-rt tasks act politely at the right moments. RT tasks will
likely immediately
On Thu, 2009-11-19 at 12:59 +, Alan Cox wrote:
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.
if (need_resched())
schedule();
aka.
cond_resched();
will
On Thu, 2009-11-19 at 14:11 +0100, Thomas Gleixner wrote:
You say NOOP by default, does this imply there is a way to change
this?
There is a sysctl: sysctl_sched_compat_yield
This makes yield() place current behind all other tasks, and sucks too
for some workloads.
--
To unsubscribe
Hi Peter,
On Thu, 19 Nov 2009 14:06:54 +0100, Peter Zijlstra wrote:
On Thu, 2009-11-19 at 12:59 +, Alan Cox wrote:
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.
if
On Thu, 2009-11-19 at 15:00 +0100, Jean Delvare wrote:
cond_resched();
Are you saying that most calls to yield() should be replaced with calls
to cond_resched()?
No, depends on the reason yield() is used. Some cases can be replaced by
locking constructs, such as a condition variable.
Hello,
On Wed, Nov 18, 2009 at 2:05 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
I think the yield()s in the device driver code means I need a small
delay before the hardware is ready which might translate to some
arbitrary let me msleep() or do not select this task in the next
scheduler run,
On Wed, 18 Nov 2009 17:28:53 +0100, Leon Woestenberg wrote:
On Wed, Nov 18, 2009 at 2:05 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Our timers are very efficient and some day we will need to make jiffies a
function and stop the timer ticking for best performance. At that point
timers are
On Wed, 18 Nov 2009, Jean Delvare wrote:
On Wed, 18 Nov 2009 17:28:53 +0100, Leon Woestenberg wrote:
On Wed, Nov 18, 2009 at 2:05 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Our timers are very efficient and some day we will need to make jiffies a
function and stop the timer ticking for
I think the yield()s in the device driver code means I need a small
delay before the hardware is ready which might translate to some
arbitrary let me msleep() or do not select this task in the next
scheduler run, EVEN IF this task is highest priority.
Yield() in a driver is almost always a
On Fri, Nov 13, 2009 at 11:03:39PM +0100, Thomas Gleixner wrote:
Q: Why put people yield() into their code ?
A: Because:
- it is less nasty than busy waiting for a long time
- it works better
...
I can see the idea of using yield() to let other tasks making progress
in situations
Hi Thomas,
On Fri, 13 Nov 2009 23:03:39 +0100 (CET), Thomas Gleixner wrote:
Jean,
On Thu, 12 Nov 2009, Jean Delvare wrote:
As far as I can see, yield() doesn't have clear semantics attached.
It's more of a utility function everyone could use as they see fit. In
that respect, I
Jean,
On Thu, 12 Nov 2009, Jean Delvare wrote:
As far as I can see, yield() doesn't have clear semantics attached.
It's more of a utility function everyone could use as they see fit. In
that respect, I understand your concerns about the coders' expectations
and how they could be dismissed by
Hello Sven,
On Sun, 08 Nov 2009 10:57:16 -0800, Sven-Thorsten Dietrich wrote:
On 11/07/2009 12:01 PM, Jean Delvare wrote:
One thing I do not understand: if yield() is a bug to RT kernels, then
we would have to remove them all? But so far, yield() still exists in
the kernel tree, and it
Hello Jean, Ben, -i2c and -rt devs,
during testing the Linux PREEMP_RT work (step-by-step being merged
with mainline) together with I2C functionality I hit the fact that the
I2C
subsystem uses yield() in some of the non-happy code paths (mostly
during chip / address probing etc).
My (embedded)
Hi Leon,
On Sat, 7 Nov 2009 20:01:59 +0100, Leon Woestenberg wrote:
during testing the Linux PREEMP_RT work (step-by-step being merged
with mainline) together with I2C functionality I hit the fact that the
I2C subsystem uses yield() in some of the non-happy code paths (mostly
during chip /
16 matches
Mail list logo
