From: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
To: linux-kernel@vger.kernel.org
Cc: len.brown@intel.com, linux-pm@vger.kernel.org, lenb@kernel.org
Subject: Re: pm_qos request for 0 cpu_dma_latency is ignored on Linus master
Date: Fri, 19 Oct 2012 18:34:39 +0100 [thread overview]
Message-ID: <20490918.t8n8AcBcDM@f17simon> (raw)
In-Reply-To: <2732999.VSJZov8CP4@f17simon>
[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]
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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
prev parent reply other threads:[~2012-10-19 17:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-19 17:28 pm_qos request for 0 cpu_dma_latency is ignored on Linus master Simon Farnsworth
2012-10-19 17:34 ` Simon Farnsworth [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20490918.t8n8AcBcDM@f17simon \
--to=simon.farnsworth@onelan.co.uk \
--cc=len.brown@intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.