Hi,
I am trying to understand at what granularity a typical Vista system will transistion out of state S0. Clearly if the system is not in S0 then no code is running. So if I am staring at the screen reading a document but not moving the mouse or typing keys does the remain in S0 or does it transisition in and out trying to save power at the micro level or does it only transition after many seconds/minutes. I assume the only thing that can bring the system back to S0 is a hardware interrupt. Clearly the RTC generates interrupts and on a multicore system this is used for timers. However, are timers ignored when the system goes out of S0 - i.e. does the RTC interrupt frequency get reprogrammed so that timers are effectively disabled. Any help on this issue would be very much appreciated.
I think that you’re confusing system states, device states and processor
states. S0 is the system state where the entire computer appears to be
running and where it is responsive to user input. Clearly your computer
remains in S0 while you are reading the screen.
Perhaps you meant to ask about processor states? Are you curious what
happens while the CPU is idle? These are referred to as C-states. C0 is
running, C1 is halted, C2 is low-power with caches snooping. Cn where n > 2
refers to states where the processor is in a low power state with caches not
snooping. Don’t confuse these with P-states, where the performance level of
the processor is adjusted while in C0.
Or did you mean to ask about device states? Are you wondering if specific
devices might be turned on and off at runtime? These are referred to as
D-states. D0 is on. D1 is less on. D2 is mostly not on. D3 is off. The
exact definitions vary from class to class.
Ask again and perhaps we can help.
- Jake Oshins
Windows Kernel Guy
wrote in message news:xxxxx@ntdev…
> Hi,
> I am trying to understand at what granularity a typical Vista system will
> transistion out of state S0. Clearly if the system is not in S0 then no
> code is running. So if I am staring at the screen reading a document but
> not moving the mouse or typing keys does the remain in S0 or does it
> transisition in and out trying to save power at the micro level or does it
> only transition after many seconds/minutes. I assume the only thing that
> can bring the system back to S0 is a hardware interrupt. Clearly the RTC
> generates interrupts and on a multicore system this is used for timers.
> However, are timers ignored when the system goes out of S0 - i.e. does the
> RTC interrupt frequency get reprogrammed so that timers are effectively
> disabled. Any help on this issue would be very much appreciated.
>
Hi Jake,
Many thanks for the reply.
I didn’t think I was confusing states - although I appreciate you double checking just in case. I had always assumed that whenever the computer was in use then it never went out of S0 and that if it went into a lower system state then the system would effectively lock the screen until brought back into S0. However, recently someone who ought to now has challenged that so I thought that I would ask the question of you guys who are certain to know. If I understand your response then my original understanding was more or less correct - but maybe you can correct me if I am wrong 
Since you mentioned processor states - yes I am curious about what happens in Vista when the CPU is idle and how this reflects itself in power management IRPs to device drivers. Or are these Cx states transparent to device drivers? Can a device driver do something that prevents the processor entering these Cx states.
At the moment I am having trouble drawing together the information I am finding in the ACPI spec, the IA32 reference manuals and how Vista actaully makes use of these.
Any pointers very much appreciated.
Chris Kelly
The screen will never remain on when the machine leaves S0. It’s not just a
matter of it seeming “locked.” It will be in D1 or lower.
Processor states are mostly transparent to device drivers. Certainly no
IRPs get sent, nor is anything else done that might keep the processor busy.
Processor state transistions can happen thousands of times per second. With
that said, on older processors and/or chipsets, you could prevent the use of
the processor states that are non-snooping just by creating lots of
continuous busmaster activity. If, for instance, your device continuously
scans a work list in memory, you will prevent the use of low power processor
states. Newer processors and chipsets have lowered the cost of moving back
and forth between the snooping and non-snooping states, which lowers the
cost of the DMA operations. But it’s still a big problem for power
management if your device does DMA when it is mostly or completely idle.
- Jake Oshins
wrote in message news:xxxxx@ntdev…
> Hi Jake,
> Many thanks for the reply.
> I didn’t think I was confusing states - although I appreciate you double
> checking just in case. I had always assumed that whenever the computer was
> in use then it never went out of S0 and that if it went into a lower
> system state then the system would effectively lock the screen until
> brought back into S0. However, recently someone who ought to now has
> challenged that so I thought that I would ask the question of you guys who
> are certain to know. If I understand your response then my original
> understanding was more or less correct - but maybe you can correct me if I
> am wrong
>
> Since you mentioned processor states - yes I am curious about what happens
> in Vista when the CPU is idle and how this reflects itself in power
> management IRPs to device drivers. Or are these Cx states transparent to
> device drivers? Can a device driver do something that prevents the
> processor entering these Cx states.
> At the moment I am having trouble drawing together the information I am
> finding in the ACPI spec, the IA32 reference manuals and how Vista
> actaully makes use of these.
> Any pointers very much appreciated.
> Chris Kelly
>
>
> states. Newer processors and chipsets have lowered the cost of moving back
and forth between the snooping and non-snooping states, which lowers the
cost of the DMA operations.
Am I correct that this means that the Windows DMA routines call some
CPU-specific logic in them to lock the processor in a snooping state?
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
No, the chipset handles it all in hardware. The PCI arbiter doesn’t grant
the bus to any devices until the processor is back into a snooping state.
(This is, of course, a simplification now that PCIe is common. But
logically, the same thing happens.) In older chips, the processor has to
transition to C0. In some newer ones, it can transition to C2.
- Jake
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>> states. Newer processors and chipsets have lowered the cost of moving
>> back
>> and forth between the snooping and non-snooping states, which lowers the
>> cost of the DMA operations.
>
> Am I correct that this means that the Windows DMA routines call some
> CPU-specific logic in them to lock the processor in a snooping state?
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
When does the CPU leave C0? Is it also controlled by hardware? Is it
configurable?
Thanks,
-Volker
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Thursday, August 09, 2007 8:51 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How often does Vista transistion out of S0No, the chipset handles it all in hardware. The PCI arbiter
doesn’t grant the bus to any devices until the processor is
back into a snooping state.
(This is, of course, a simplification now that PCIe is
common. But logically, the same thing happens.) In older
chips, the processor has to transition to C0. In some newer
ones, it can transition to C2.
- Jake
“Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> >> states. Newer processors and chipsets have lowered the cost of
> >> moving back and forth between the snooping and
> non-snooping states,
> >> which lowers the cost of the DMA operations.
> >
> > Am I correct that this means that the Windows DMA routines
> call some
> > CPU-specific logic in them to lock the processor in a
> snooping state?
> >
> > –
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>
>
Software controls it. The simplest way is to execute a HLT instruction.
Deeper C-states can be invoked on some processors through MSRs and on others
by manipulating chipset registers.
- Jake
“Moebius, V.” wrote in message
news:xxxxx@ntdev…
When does the CPU leave C0? Is it also controlled by hardware? Is it
configurable?
Thanks,
-Volker
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
> Sent: Thursday, August 09, 2007 8:51 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] How often does Vista transistion out of S0
>
> No, the chipset handles it all in hardware. The PCI arbiter
> doesn’t grant the bus to any devices until the processor is
> back into a snooping state.
> (This is, of course, a simplification now that PCIe is
> common. But logically, the same thing happens.) In older
> chips, the processor has to transition to C0. In some newer
> ones, it can transition to C2.
>
> - Jake
>
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> >> states. Newer processors and chipsets have lowered the cost of
> >> moving back and forth between the snooping and
> non-snooping states,
> >> which lowers the cost of the DMA operations.
> >
> > Am I correct that this means that the Windows DMA routines
> call some
> > CPU-specific logic in them to lock the processor in a
> snooping state?
> >
> > –
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>
>