(please cc me on replies - I'm not directly subscribed to linux-kernel or linux-pm)
I'm trying to track down why a Sandybridge system with a PCIe to PCI riser
has problems after enabling GPU RC6, and I've reduced my problem to the menu
cpuidle governor selecting high C-states from intel_idle, even though I've
given a cpu_dma_latency requirement of 0 usecs.
I have a TV capture card in the riser, and it appears that I get data lost
whenever the package enters a high C state. My userspace opens
/dev/cpu_dma_latency and writes (uint32_t)0 to this fd whenever we have things
on-screen, closing the fd when we put the screen into DPMS off states.
However, even with a userspace provided request of 0 usec, I'm seeing the CPU
cores (and hence the entire package when GPU RC6 is enabled) enter C6 state.
I've confirmed that forcing the governor to limit itself to C0 fixes my
problem with:
# for state in /sys/devices/system/cpu/cpu*/cpuidle/state[1-9]*/disable ; do echo 1 > $state ; done
What do I need to do to get the menu cpuidle governor and the intel_idle
cpuidle driver to respect the /dev/cpu_dma_latency pm_qos request of 0 usec
and keep the Sandybridge CPU package out of low C states? Note that a CPU
core in low C state is fine, as long as the DMA latency stays low.
My goal is to keep the system in high-performance state when we're rendering
digital signage on screen (as any glitching may upset viewers, and compared
to the screen's full power use, we're irrelevant), but to go into lower power
states when the screen is off (when we're only drawing power to keep the
administrator interface available).
My kernel is currently 3.7-rc1+, based on Linus git of Tuesday 16th October
2012. I'm happy to try patches, even if all they get you is better debug
output to work out why the userspace request is ignored.
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
Sorry for the noise. I've just found it's my code at fault - we changed
to a 10,000 usec PM request for most platforms a while ago.
Simon
On Friday 19 October 2012 18:28:18 Simon Farnsworth wrote:
> (please cc me on replies - I'm not directly subscribed to linux-kernel or linux-pm)
>
> I'm trying to track down why a Sandybridge system with a PCIe to PCI riser
> has problems after enabling GPU RC6, and I've reduced my problem to the menu
> cpuidle governor selecting high C-states from intel_idle, even though I've
> given a cpu_dma_latency requirement of 0 usecs.
>
> I have a TV capture card in the riser, and it appears that I get data lost
> whenever the package enters a high C state. My userspace opens
> /dev/cpu_dma_latency and writes (uint32_t)0 to this fd whenever we have things
> on-screen, closing the fd when we put the screen into DPMS off states.
>
> However, even with a userspace provided request of 0 usec, I'm seeing the CPU
> cores (and hence the entire package when GPU RC6 is enabled) enter C6 state.
>
> I've confirmed that forcing the governor to limit itself to C0 fixes my
> problem with:
>
> # for state in /sys/devices/system/cpu/cpu*/cpuidle/state[1-9]*/disable ; do echo 1 > $state ; done
>
> What do I need to do to get the menu cpuidle governor and the intel_idle
> cpuidle driver to respect the /dev/cpu_dma_latency pm_qos request of 0 usec
> and keep the Sandybridge CPU package out of low C states? Note that a CPU
> core in low C state is fine, as long as the DMA latency stays low.
>
> My goal is to keep the system in high-performance state when we're rendering
> digital signage on screen (as any glitching may upset viewers, and compared
> to the screen's full power use, we're irrelevant), but to go into lower power
> states when the screen is off (when we're only drawing power to keep the
> administrator interface available).
>
> My kernel is currently 3.7-rc1+, based on Linus git of Tuesday 16th October
> 2012. I'm happy to try patches, even if all they get you is better debug
> output to work out why the userspace request is ignored.
>
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com