Re: [ 028/108] sched/nohz: Rewrite and fix load-avg computation --again

From: Ben Hutchings
Date: Thu Jul 26 2012 - 18:01:24 EST


On Thu, Jul 26, 2012 at 11:25:37PM +0200, Peter Zijlstra wrote:
> On Tue, 2012-07-24 at 15:06 +0100, Ben Hutchings wrote:
> > On Mon, 2012-07-23 at 02:07 +0100, Ben Hutchings wrote:
> > > 3.2-stable review patch. If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
> > >
> > > commit 5167e8d5417bf5c322a703d2927daec727ea40dd upstream.
> > >
> > > Thanks to Charles Wang for spotting the defects in the current code:
> > >
> > > - If we go idle during the sample window -- after sampling, we get a
> > > negative bias because we can negate our own sample.
> > >
> > > - If we wake up during the sample window we get a positive bias
> > > because we push the sample to a known active period.
> > >
> > > So rewrite the entire nohz load-avg muck once again, now adding
> > > copious documentation to the code.
> > [...]
> >
> > Based on <http://bugs.debian.org/674153>, I think we also need:
> >
> > 556061b sched/nohz: Fix rq->cpu_load[] calculations
> > 5aaa0b7 sched/nohz: Fix rq->cpu_load calculations some more
> >
> > Does this ('sched/nohz: Rewrite and fix load-avg computation -- again')
> > depend in any way on those, or are they separate fixes?
>
> they might touch on a few entry points but the logic is separate.
>
> ->cpu_load[] is per-cpu weight tracking for the load-balancer.

That's what I thought, so I went ahead with just the one.
Should I queue up the other two for a future 3.2.y update?

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
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/