Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[Ingo Molnar]

* Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote:

> >well, no. Unless i misunderstood your application model, you want
> >threads to sleep until they are woken up. So you want a very basic
> >sleep/wake mechanism. But yield_to() does not achieve that! yield_to()
> >will yield to _already running_ (i.e. in the runqueue) threads. Using
> >yield() (or yield_to()) for this is really suboptimal. By using a futex
> >based mechanism you get a very nice schedule/sleep pattern.
> 
> i mentioned earlier today in a message to bill huey that JACK is
> really a user-space cooperative scheduler. JACK's "scheduler" knows
> who is doing what and when, and if it doesn't then it can't work at
> all. so the scenario you describe is impossible and/or broken.

that might be all well and good, but i believe you still dont understand
my point: for yield_to() to work the target task _needs to be running_. 
I.e. it needs to be in TASK_RUNNING state. You cannot yield_to() a
sleeping task out of thin air: any 'targeted wakeup' needs some wait
object. Either a futex, a signal or a fifo, or something else. The waker
has to identify the wait object somehow.

so if you want to use yield_to() (which is a targeted variant of
sched_yield()) for this purpose, it wont and cannot work. Maybe you
thought of some other API, but yield_to() just doesnt cut it.

in theory it would be possible to add two new syscalls: sys_suspend()
and sys_wakeup(tid), where suspend would just enter TASK_INTERRUPTIBLE
without being on any waitqueue, and sys_wakeup() would just do a
process_wakeup() of the target task (if the target task is in
TASK_INTERRUPTIBLE state). But this would probably only be marginally
faster than futexes, and you'd still have all the problems with not
having this API on 2.4 kernels. But it would have one big advantage: it
would be evidently and trivially RT-safe :-)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/