Variable ticks

Variable ticks

[Bill Davidsen]

I was thinking about variable tick times, and I can think of three 
classes of action needing CPU attention.
- device interrupts, which occur at no predictable time but would pull 
the CPU out of a HLT or low power state.
- process sleeps of various kinds, which have a known time of occurence.
- polled devices...

Question one, are there other actions to consider?

Question two, what about those polled devices?

I've been asked to give a high level overview of the recent discussion 
for a meeting, and while I want to keep it at the level of "slower 
clock, fewer interrupts" and "faster clock, better sleep resolution," I 
don't want to leave out any important issues, or be asked a question 
(like how to handle polling devices) when I have no idea what people are 
thinking in an area.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

RE: Variable ticks

[Brown, Len]

 
>I was thinking about variable tick times, and I can think of three 
>classes of action needing CPU attention.
>- device interrupts, which occur at no predictable time but would pull 
>the CPU out of a HLT or low power state.
>- process sleeps of various kinds, which have a known time of 
>occurence.
>- polled devices...
>
>Question one, are there other actions to consider?

Yes.
Speaking for ACPI C3 state, note that DMA also
wakes up the CPU -- even if there was no device interrupt.
(aka, "the trouble with USB")

>Question two, what about those polled devices?

it is a real challenge to save power under such conditions,
unless you can throttle the polling rate such that
the processor can actually enters idle while polling
is underway.

>I've been asked to give a high level overview of the recent discussion 
>for a meeting, and while I want to keep it at the level of "slower 
>clock, fewer interrupts" and "faster clock, better sleep 
>resolution," I 
>don't want to leave out any important issues, or be asked a question 
>(like how to handle polling devices) when I have no idea what 
>people are thinking in an area.

>From a power management point of view, what is important
is what we do when idle.  ie. on my laptop, from a power
savings point of view, I wouldn't care
much if HZ=1000 all the time if HZ=0 when in idle.

Outside of idle, the tick rate is much less important to
power savings, unless the change in tick rate was significant
enough to change the load enough that we'd want to change the
target non-idle MHz of the processor.

cheers,
-Len

Re: Variable ticks

[Bill Davidsen]

Brown, Len wrote:
>  
> 
>>I was thinking about variable tick times, and I can think of three 
>>classes of action needing CPU attention.
>>- device interrupts, which occur at no predictable time but would pull 
>>the CPU out of a HLT or low power state.
>>- process sleeps of various kinds, which have a known time of 
>>occurence.
>>- polled devices...
>>
>>Question one, are there other actions to consider?
> 
> 
> Yes.
> Speaking for ACPI C3 state, note that DMA also
> wakes up the CPU -- even if there was no device interrupt.
> (aka, "the trouble with USB")

Trouble? Why would USB do DMA unless there was a device activity?
> 
> 
>>Question two, what about those polled devices?
> 
> 
> it is a real challenge to save power under such conditions,
> unless you can throttle the polling rate such that
> the processor can actually enters idle while polling
> is underway.
> 
> 
>>I've been asked to give a high level overview of the recent discussion 
>>for a meeting, and while I want to keep it at the level of "slower 
>>clock, fewer interrupts" and "faster clock, better sleep 
>>resolution," I 
>>don't want to leave out any important issues, or be asked a question 
>>(like how to handle polling devices) when I have no idea what 
>>people are thinking in an area.
> 
> 
> From a power management point of view, what is important
> is what we do when idle.  ie. on my laptop, from a power
> savings point of view, I wouldn't care
> much if HZ=1000 all the time if HZ=0 when in idle.

That could hurt the polling performance, all right. ;-)
> 
> Outside of idle, the tick rate is much less important to
> power savings, unless the change in tick rate was significant
> enough to change the load enough that we'd want to change the
> target non-idle MHz of the processor.

Isn't that more or less what on demand does?

Thanks for the feedback, I can probably just say that DMA wakes the CPU 
from C3 and let it ride, I don't want to skip it, but neither do I need 
to go into detail.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

RE: Variable ticks

[Brown, Len]

 
>>>Question one, are there other actions to consider?
>> 
>> 
>> Yes.
>> Speaking for ACPI C3 state, note that DMA also
>> wakes up the CPU -- even if there was no device interrupt.
>> (aka, "the trouble with USB")
>
>Trouble? Why would USB do DMA unless there was a device activity?

look here:
http://www.google.com/search?hl=en&q=usb+selective+suspend

Linux is working on it too, but it is in development.

cheers,
-Len

RE: Variable ticks

[Lee Revell]

On Mon, 2005-07-25 at 17:19 -0400, Brown, Len wrote:
>  >>>Question one, are there other actions to consider?
> >> 
> >> 
> >> Yes.
> >> Speaking for ACPI C3 state, note that DMA also
> >> wakes up the CPU -- even if there was no device interrupt.
> >> (aka, "the trouble with USB")
> >
> >Trouble? Why would USB do DMA unless there was a device activity?
> 
> look here:
> http://www.google.com/search?hl=en&q=usb+selective+suspend
> 
> Linux is working on it too, but it is in development.

What about audio?  If there is a sound server running then you're going
to have a constant stream of interrupts and DMA activity from the sound
card even if the machine is idle and there aren't any sounds playing.

Lee

Re: Variable ticks

[Bill Davidsen]

Brown, Len wrote:
>  
> 
>>>>Question one, are there other actions to consider?
>>>
>>>
>>>Yes.
>>>Speaking for ACPI C3 state, note that DMA also
>>>wakes up the CPU -- even if there was no device interrupt.
>>>(aka, "the trouble with USB")
>>
>>Trouble? Why would USB do DMA unless there was a device activity?
> 
> 
> look here:
> http://www.google.com/search?hl=en&q=usb+selective+suspend
> 
> Linux is working on it too, but it is in development.

Somehow I didn't ask that right... The stuff on selective disable is 
interesting, but my question is why a USB device, call it a keyboard, 
would do DMA unless I press a key, at which point response will be 
better if the CPU wakes up out of C3.

I understand that specialty attachments may send what amounts to keep 
alives, or gather data (webcam) you don't want, but the typical mouse 
and KB would seem to be things which generate DMA at user initiation, 
and would not be blocked for low power, only for suspend.
-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

RE: Variable ticks

[Brown, Len]

 
>>>Trouble? Why would USB do DMA unless there was a device activity?
>> 
>> 
>> look here:
>> http://www.google.com/search?hl=en&q=usb+selective+suspend
>> 
>> Linux is working on it too, but it is in development.
>
>Somehow I didn't ask that right... The stuff on selective disable is 
>interesting, but my question is why a USB device, call it a keyboard, 
>would do DMA unless I press a key, at which point response will be 
>better if the CPU wakes up out of C3.
>
>I understand that specialty attachments may send what amounts to keep 
>alives, or gather data (webcam) you don't want, but the typical mouse 
>and KB would seem to be things which generate DMA at user initiation, 
>and would not be blocked for low power, only for suspend.

USB's hardware architecture was optimized for cost and ease of use,
it was not optimized for performance or power savings.

We need software disable because the USB hardware will keep
the memory bus busy constantly even if all the
actual USB devices are idle.  The power cost is that the CPU
is prevented from deep sleep so that it can snoop USB's
(idle) memory activity.

-Len

RE: Variable ticks

[Zwane Mwaikambo]

On Mon, 25 Jul 2005, Lee Revell wrote:

> On Mon, 2005-07-25 at 17:19 -0400, Brown, Len wrote:
> >  >>>Question one, are there other actions to consider?
> > >> 
> > >> 
> > >> Yes.
> > >> Speaking for ACPI C3 state, note that DMA also
> > >> wakes up the CPU -- even if there was no device interrupt.
> > >> (aka, "the trouble with USB")
> > >
> > >Trouble? Why would USB do DMA unless there was a device activity?
> > 
> > look here:
> > http://www.google.com/search?hl=en&q=usb+selective+suspend
> > 
> > Linux is working on it too, but it is in development.
> 
> What about audio?  If there is a sound server running then you're going
> to have a constant stream of interrupts and DMA activity from the sound
> card even if the machine is idle and there aren't any sounds playing.

Doesn't artsd at least close the audio device after some configurable idle 
time? In which case that sounds like a userspace issue.

RE: Variable ticks

[Lee Revell]

On Wed, 2005-07-27 at 02:13 -0600, Zwane Mwaikambo wrote: 
> > What about audio?  If there is a sound server running then you're going
> > to have a constant stream of interrupts and DMA activity from the sound
> > card even if the machine is idle and there aren't any sounds playing.
> 
> Doesn't artsd at least close the audio device after some configurable idle 
> time? In which case that sounds like a userspace issue.

Well, as of ALSA 1.0.9 which does software mixing and volume control by
default, all the sound servers are obsolete.  So this should be a
non-issue with a modern distro.

As far as legacy support, AFAIK esd and artsd both grab the sound device
on startup and never release it.

Lee

Re: Variable ticks

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

On Wed, 27 Jul 2005 16:43:07 EDT, Lee Revell said:

> As far as legacy support, AFAIK esd and artsd both grab the sound device
> on startup and never release it.

'man esd' on a FC4 system includes:

         -as SECS     free audio device after SECS of inactivity

and has '-as 2' specified in /etc/esd.conf.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

RE: Variable ticks

[Zwane Mwaikambo]

On Wed, 27 Jul 2005, Lee Revell wrote:

> On Wed, 2005-07-27 at 02:13 -0600, Zwane Mwaikambo wrote: 
> > > What about audio?  If there is a sound server running then you're going
> > > to have a constant stream of interrupts and DMA activity from the sound
> > > card even if the machine is idle and there aren't any sounds playing.
> > 
> > Doesn't artsd at least close the audio device after some configurable idle 
> > time? In which case that sounds like a userspace issue.
> 
> Well, as of ALSA 1.0.9 which does software mixing and volume control by
> default, all the sound servers are obsolete.  So this should be a
> non-issue with a modern distro.
> 
> As far as legacy support, AFAIK esd and artsd both grab the sound device
> on startup and never release it.

I just setup KDE/artsd to release the sound device after 30seconds and it 
seems to work.