pm_qos request for 0 cpu_dma_latency is ignored on Linus master
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
Quoted 31 lines · 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 acpu_dma_latencyrequirement 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_latencyand 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 ; doneWhat do I need to do to get the menu cpuidle governor and the
intel_idlecpuidle driver to respect the/dev/cpu_dma_latencypm_qosrequest 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).
Quoted 4 lines
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
(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.
Signature · 4 lines
Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com