lkml.org 
[lkml]   [2009]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [BUG] How to get real-time priority using idle priority
From
Date
On Thu, 2009-01-15 at 11:30 +0100, Mike Galbraith wrote:
> On Thu, 2009-01-15 at 11:14 +0100, Peter Zijlstra wrote:
> >
> > Which leads me to suggest the following
> >
> > ---
> > diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> > index 8e1352c..f2d2d94 100644
> > --- a/kernel/sched_fair.c
> > +++ b/kernel/sched_fair.c
> > @@ -283,7 +283,7 @@ static void update_min_vruntime(struct cfs_rq
> > *cfs_rq)
> > struct sched_entity,
> > run_node);
> >
> > - if (vruntime == cfs_rq->min_vruntime)
> > + if (!cfs_rq->curr)
> > vruntime = se->vruntime;
> > else
> > vruntime = min_vruntime(vruntime, se->vruntime);
>
> Aha. Yeah, I'll re-test with that instead.

Works a treat.

> > The below can be split into 3 patches:
> >
> > - the idle weight change (do we really need that? why?)
>
> I saw idle tasks slamming extremely far. I'll verify, less is more.

time advanced in 100ms
weight=2
64765.988352
67012.881408
88501.412352

weight=3
35496.181411
34130.971298
35497.411573

Measured from an RT shell doing..
while sleep .1; do cat /proc/sched_debug >> /debug; done
..for a pinned chew. Not necessarily gnats-arse accurate, but good
enough to see the margin of error is pretty high with weight=2.

Your call.

-Mike



\
 
 \ /
  Last update: 2009-01-15 12:41    [W:0.067 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site