Re: A few questions and issues with dynticks, NOHZ and powertop

From: david
Date: Mon Apr 05 2010 - 14:45:57 EST


On Mon, 5 Apr 2010, Arjan van de Ven wrote:

On 4/5/2010 8:14, Paul E. McKenney wrote:
So the main issue is that for many workloads, it is best to run full bore
and get done quickly, thus allowing the entire machine to be powered down?

yep

Race To Idle works extremely well in a batch type situation where there is not going to be any work to do after you finish what you have.

It doesn't work quite as well if you are going to have new work to do in the near future.

You cannot power down the entire machine if you have to look for user input.

It takes time (and power) to shut down and start back up, if you are going to have more work to do before you can make the complete cycle (and save more power than it costs to make the transitions), it's best to stay at full power, even if you are idle.


As an example, video/audio playback.

This requires relativly little cpu, but it needs it frequently (to keep the hardware buffers filled), and you cannot power down even when the cpu is idle.

But you could save power by disabling cores, switching to a slower clock speed, etc while still having one core remaining awake all the time.


The key is to look at what you are waiting for. If you are just waiting for the processing to finish, race to idle is great. However if you are waiting for the outside world or for a clock tick you need to look into the exact situation more closely.

David Lang

If so, it seems likely that there would be some workloads that were sometimes
unable to use all the CPUs, in which case shutting down (idling, offlining,
dyntick-idling, whatever) the excess CPUs might nevertheless be the right
thing to do.

but the point is that the normal scheduler + idle behavior gives you exactly that
in a natural way !
If you don't have enough work (tasks) to keep all cores busy, the others are and stay idle.
--
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/

--
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/