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

[Paul Davis]

>(it would be cleaner to use POSIX semaphores for this, but you mentioned
>the requirement for the mechanism to work on 2.4 kernels too - pthread
>spinlocks will work inter-process on 2.4 too, and will schedule nicely.)

can't work. pthread interprocess spinlocks are hopelessly non-RT safe
in 2.4/linuxthreads. or they were the last time i looked - they rely
on sending signals and passing through the whole pthread layer.

this is why we use FIFO's right now: fast, portable (though not to OSX
<grin> - we have to use Mach ports to get enough speed there), and a
PITA :)

>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.

please keep in mind this description of JACK. there is no doubt some
remnant of the work i did on scheduler activations in the mid-90's
left floating around in my head and shaping JACK in mysterious ways :)

--p "kernel-to-user-space: thread <tid> blocked on disk i/o. please advise."


-
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/