[Intel-gfx] Interrupt latency on some 945GM platforms
Jesse Barnes
jbarnes at virtuousgeek.org
Fri Sep 17 18:30:26 CEST 2010
Yeah if that works we could definitely add some qos calls to the driver. When vblanks are alive we'd need a latency less tha the refresh rate, and when commands are oustanding we'd probably want it even lower.
Vasily, can you try the qos workaround on your machine and see if it works too?
Thanks,
"Simon Farnsworth" <simon.farnsworth at onelan.co.uk> wrote:
>On Thursday 16 September 2010, Vasily Khoruzhick <anarsoul at gmail.com> wrote:
>> В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
>> > > > processor.max_cstate=2
>> > >
>> > > Nope, it doesn't work with max_cstate=2
>> >
>> > Perhaps intel_idle is being used? Any mention of it in dmesg?
>>
>> Sitsofe, maybe you misunderstood me, I mean with max_cstate=1 graphics is
>> smooth, with higher values (i.e. max_cstate=2) graphics is jerky.
>>
>> Btw, Jesse, any comments/solutions/workarounds except one with
>> processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo
>> bugzilla?
>
>This looks like a problem I've seen on some hardware.
>
>My workaround has been to use the pm_qos /dev/cpu_dma_latency interface to
>request a maximum latency of 1ms (value chosen as definitely small enough - a
>larger value may be better, but I don't care about power saving at runtime on
>my kit).
>
>If it's happening on other kit, perhaps the i915 driver should make a suitable
>pm_qos request itself. Jesse, can you comment?
>--
>Simon Farnsworth
>Software Engineer
>ONELAN Limited
>http://www.onelan.com/
>
--
Jesse Barnes, Intel Open Source Technology Center
More information about the Intel-gfx
mailing list