From: Paul E. McKenney on
On Mon, Apr 05, 2010 at 09:23:16AM -0700, Arjan van de Ven wrote:
> On 4/5/2010 9:22, Paul E. McKenney wrote:
> >On Mon, Apr 05, 2010 at 09:07:33AM -0700, 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
> >>
> >>>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.
> >
> >So your earlier objection was not to dyntick-idle as such, but rather
> >to artificially constraining the scheduler to induce dyntick-idle?
>
> my objection was against the notion that offlining cpus helps power/energy ;-)

Fair enough, at least in general. I should hasten to add that Lai's
patch also helps in the case where NR_CPUS is greater than the number
of CPUs on the system.

Thanx, Paul
--
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: david on
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(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/
>
--
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 4/5/2010 11:44, david(a)lang.hm wrote:
> 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.

for the things we're talking about here (memory controllers etc) we're talking
about single to low double digit microseconds (or even less) of time to go up and down.
Many of the things you talk about are in the millisecond timeframe.

--
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: Paul E. McKenney on
On Mon, Apr 05, 2010 at 12:48:59PM -0700, Arjan van de Ven wrote:
> On 4/5/2010 11:44, david(a)lang.hm wrote:
> >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.
>
> for the things we're talking about here (memory controllers etc) we're talking
> about single to low double digit microseconds (or even less) of time to go up and down.
> Many of the things you talk about are in the millisecond timeframe.

So the decision will depend not only on the workload itself, but also
on the hardware that the workload uses.

Thanx, Paul
--
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: Dominik Brodowski on
On Sun, Apr 04, 2010 at 08:42:43PM -0700, Arjan van de Ven wrote:
> On 4/4/2010 3:47, Dominik Brodowski wrote:
> >Hey,
> >
> >On Sat, Apr 03, 2010 at 04:53:26PM -0700, Dmitry Torokhov wrote:
> >>On Sun, Apr 04, 2010 at 12:33:28AM +0200, Dominik Brodowski wrote:
> >>>
> >>>4) SynPS/2 touchpad:
> >>>Why does moving the touchpad lead to sooo many IRQs? I can't look as fast
> >>>as the mouse pointer seems to get new data:
> >>> 62,5% (473,1)<interrupt> : PS/2 keyboard/mouse/touchpad
> >>>
> >>
> >>80 pps @ 6 bytes/packet = 480 interrupts/sec.
> >>
> >>You can try using psmouse.rate=40 to limit it to 40 pps which should
> >>bring it to the rate of standard PS/2 mouse at the expense of
> >>sensitivity...
> >
> >as a sidenote: if we know -- like here -- that the next IRQ will be issued
> >soon, in approximately 1.75 ms (well, at least on my system), might it make
> >sense to make tick_nohz_get_sleep_length() smarter to know about this?
>
> yes and no.
>
> if you are very sure (95%+ or so) then absolutely it needs to know about this
> so that the C state selection code can make a better decision.
> Right now it tries to look at history to guess this delay.
>
> Unfortunately we do not currently have such a concept in the code to make this
> work... but it'd be really nice to have.

Dmitry, are we "very sure" in this touchpad case?

Best,
Dominik

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