From: Peter Zijlstra on
On Thu, 2010-07-08 at 17:59 +0200, Peter Zijlstra wrote:

> OK, so Arjan said the gain could come from tricking the idle governor
> into not using deeper C states. He also said he significantly cured said
> governor in .35.
>
> Mike could you re-run your netperf tests that showed the 10% throughput
> gain? Hopefully the fixed governor will yield the same result and we can
> kill off this ratelimit thing.

FWIW, on my test-box, 35-rc4-tip, using ondemand:

with nohz_ratelimit() : ~2119.54 MB/s
without nohz_ratelimit() : ~2353.03 MB/s

Seems to suggest we should simply kill the thing..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mike Galbraith on
On Thu, 2010-07-08 at 15:23 +0200, Peter Zijlstra wrote:
> On Thu, 2010-07-08 at 21:46 +0900, Norbert Preining wrote:
> > Looks promising, reverting the old patch, adding that one, building,
> > running, unplugging ppower, powertop runs now since some time,
> > it seems that we are back to better situation:
>
> Hrmm, Mike seems you wrecked power usage..
>
> So nohz_ratelimit() prevents us from entering NOHZ when the last attempt
> was less than 1/2 a jiffy ago (fwiw: NSEC_PER_SEC/HZ == TICK_NSEC).
>
> Its either entering idle or irq_exit trying to enter nohz state, if we
> keep skipping it it means that we get enough interrupt activity to
> render nohz useless anyway.. so not quite sure how this wrecks things.

You can't win at this game.

I really don't like giving up anything, but thinking about it, if I were
the maintainer, I'd just revert the damn thing as being more trouble
than it's worth.

It makes a large difference at the extreme end of the spectrum when
scheduling cross cpu (which we now actively try to do to maximize ramp
throughput), but ever less as frequency diminishes. I've yet to see a
load I can respect at close to max ctx frequency, where optimization
earns it's beans and biscuits.

Ego: If thine eye offends thee, pluck it out.

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mike Galbraith on
On Thu, 2010-07-08 at 17:59 +0200, Peter Zijlstra wrote:
> On Thu, 2010-07-08 at 15:23 +0200, Peter Zijlstra wrote:
> > On Thu, 2010-07-08 at 21:46 +0900, Norbert Preining wrote:
> > > Looks promising, reverting the old patch, adding that one, building,
> > > running, unplugging ppower, powertop runs now since some time,
> > > it seems that we are back to better situation:
> >
> > Hrmm, Mike seems you wrecked power usage..
> >
> > So nohz_ratelimit() prevents us from entering NOHZ when the last attempt
> > was less than 1/2 a jiffy ago (fwiw: NSEC_PER_SEC/HZ == TICK_NSEC).
> >
> > Its either entering idle or irq_exit trying to enter nohz state, if we
> > keep skipping it it means that we get enough interrupt activity to
> > render nohz useless anyway.. so not quite sure how this wrecks things..
>
> OK, so Arjan said the gain could come from tricking the idle governor
> into not using deeper C states. He also said he significantly cured said
> governor in .35.
>
> Mike could you re-run your netperf tests that showed the 10% throughput
> gain? Hopefully the fixed governor will yield the same result and we can
> kill off this ratelimit thing.

The gain is (well was last time I checked), but as noted, I'd just call
it a misguided optimization and be done with it.

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on
On Thu, 2010-07-08 at 21:40 +0200, Mike Galbraith wrote:
> > Mike could you re-run your netperf tests that showed the 10% throughput
> > gain? Hopefully the fixed governor will yield the same result and we can
> > kill off this ratelimit thing.
>
> The gain is (well was last time I checked), but as noted, I'd just call
> it a misguided optimization and be done with it.

It would still be good to know what your machine does, if you can still
see a difference there might still be something to look at.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arjan van de Ven on
On Thu, 08 Jul 2010 22:44:14 +0200
Peter Zijlstra <peterz(a)infradead.org> wrote:

> On Thu, 2010-07-08 at 21:40 +0200, Mike Galbraith wrote:
> > > Mike could you re-run your netperf tests that showed the 10%
> > > throughput gain? Hopefully the fixed governor will yield the same
> > > result and we can kill off this ratelimit thing.
> >
> > The gain is (well was last time I checked), but as noted, I'd just
> > call it a misguided optimization and be done with it.
>
> It would still be good to know what your machine does, if you can
> still see a difference there might still be something to look at.
>

yeah and if you give me a reason / workload to improve the idle
governor even more.....


--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/