lkml.org 
[lkml]   [2006]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RT task scheduling

* Darren Hart <darren@dvhart.com> 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. 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.]

my gut feeling is that it would be wrong to integrate this feature into
smpnice: SCHED_FIFO is about determinism, and smpnice is a fundamentally
statistical approach. Also, smpnice doesnt have to try as hard to pick
the right task as rt_overload does, so there would be constant
'friction' between "overhead" optimizations (dont be over-eager) and
"latency" optimizations (dont be _under_-eager). So i'm quite sure we
want this feature separate. [nevertheless i'd happy to be proven wrong
via some good and working smpnice based solution]

in any case, i'll check your -rt testcase to see why it fails.

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

\
 
 \ /
  Last update: 2006-04-06 09:43    [W:0.136 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site