Ingo Molnar wrote:
* Darren Hart <[email protected]> wrote:
My last mail specifically addresses preempt-rt, but I'd like to know
people's thoughts regarding this issue in the mainline kernel. Please
see my previous post "realtime-preempt scheduling - rt_overload
behavior" for a testcase that produces unpredictable scheduling
results.
the rt_overload feature i intend to push upstream-wards too, i just
didnt separate it out of -rt yet.
"RT overload scheduling" is a totally orthogonal mechanism to the SMP
load-balancer (and this includes smpnice too) that is more or less
equivalent to having a 'global runqueue' for real-time tasks, without
the SMP overhead associated with that. If there is no "RT overload" [the
common case even on Linux systems that _do_ make use of RT tasks
occasionally], the new mechanism is totally inactive and there's no
overhead. But once there are more RT tasks than CPUs, the scheduler will
do "global" decisions for what RT tasks to run on which CPU.
Is this good enough? Isn't it possible with the current
try_to_wake_up() implementation (with or without smpnice) for two RT
tasks to end up on the same CPU even when there are less RT tasks than CPUs?
To put even
less overhead on the mainstream kernel, i plan to introduce a new
SCHED_FIFO_GLOBAL scheduling policy to trigger this behavior. [it doesnt
make much sense to extend SCHED_RR in that direction.]
I wouldn't have thought a new policy was necessary. Why not just do
this for all SCHED_FIFO (or even all RT) tasks?
BTW Does any body in the real world actually use SCHED_RR?
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
