[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1232019428.5720.8.camel@marge.simson.net>
Date: Thu, 15 Jan 2009 12:37:08 +0100
From: Mike Galbraith <efault@....de>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Brian Rogers <brian@...w.org>, Ingo Molnar <mingo@...e.hu>,
linux-kernel@...r.kernel.org
Subject: Re: [BUG] How to get real-time priority using idle priority
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists