[Intel-gfx] [TERRIBLE PATCH] Re: [regression?] i915 generating wakeups even when idle

[Andrew Lutomirski]

On Thu, Dec 9, 2010 at 1:23 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> On Thu, 9 Dec 2010 12:47:52 -0500
> Andrew Lutomirski <luto at mit.edu> wrote:
>
>> On Thu, Dec 9, 2010 at 12:20 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
>> > On Wed, 8 Dec 2010 13:33:20 -0500
>> > Andrew Lutomirski <luto at mit.edu> wrote:
>> >
>> >> On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski <luto at mit.edu> wrote:
>> >> > On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> >> >> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski <luto at mit.edu> wrote:
>> >> >>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <luto at mit.edu> wrote:
>> >> >>> > Hi all-
>> >> >>> >
>> >> >>> > Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 +
>> >> >>> > 2.6.36.1, i915 started generating exactly 50 interrupts per second
>> >> >>> > (suspiciously equal to my refresh rate) when X is running.  I have the
>> >> >>> > Xorg driver 2.12.0 (specifically
>> >> >>> > xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64).  When I switch to a text
>> >> >>> > console but leave X running, the interrupts stop.
>> >> >>> >
>> >> >>> > Any ideas what to look at?
>> >> >>>
>> >> >>> Quitting compiz fixes it.  Suspending compiz also fixes it.
>> >> >>
>> >> >> So it is the vblank interrupt. The vblank interrupt is get alive for a few
>> >> >> seconds after the last use. If it keeps going, then either the system is
>> >> >> as idle as you believe or we lost track of the last user and forget to
>> >> >> switch off the interrupt.
>> >> >>
>> >> >> drm.debug=0xf (echo 0xf > /sys/module/drm/parameters/debug) will have the
>> >> >> gory details of who/when triggers the vblank interrupt.
>> >> >> -Chris
>> >> >
>> >> > It's the seconds on the clock.  That causes activity once per second,
>> >> > which looks like this:
>> >> >
>> >>
>> >> [...]
>> >>
>> >> >
>> >> > Maybe that "several seconds" (5, according to the source) timer is way
>> >> > too long.  Is there any reason that drm_vblank_put doesn't turn off
>> >> > interrupts immediately (or, at the latest, on the very next vblank
>> >> > interrupt)?  After all, preventing deep sleep whenever there is
>> >> > display activity every five seconds seems like a waste of power.
>> >>
>> >> This patch fixes it.  It's obviously not ready for prime time, but if
>> >> you're OK with the idea I can fix it up and submit it.
>> >>
>> >> Signed-off-by: Andy Lutomirski <luto at mit.edu>
>> >>
>> >> Diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> >> index 9d3a503..49eca3f 100644
>> >> --- a/drivers/gpu/drm/drm_irq.c
>> >> +++ b/drivers/gpu/drm/drm_irq.c
>> >> @@ -471,7 +471,7 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
>> >>
>> >>       /* Last user schedules interrupt disable */
>> >>       if (atomic_dec_and_test(&dev->vblank_refcount[crtc]))
>> >> -             mod_timer(&dev->vblank_disable_timer, jiffies + 5*DRM_HZ);
>> >> +             mod_timer(&dev->vblank_disable_timer, jiffies);
>> >>  }
>> >>  EXPORT_SYMBOL(drm_vblank_put);
>> >
>> > This will just move the problem around a bit; 5s is arguably too long
>> > to wait before disabling interrupts, but having a second hand or
>> > blinking : in your clock is the real issue here.  Why don't you disable
>> > that instead?
>>
>> I did.
>>
>> But I might also scroll a webpage every second or so (or have a
>> webpage loaded at some point that updates itself every second) and I
>> see no reason to prevent the system from going into its maximum sleep
>> state in between updates.
>>
>> IOW, I think we should optimize for mostly-idle machines in addition
>> to completely-idle machines.
>
> It's probably safe to reduce the timeout quite a bit (maybe to 500ms or
> so); the idea behind 5s was just to avoid whacking the interrupt
> hardware too frequently and to avoid situations where we continually
> enable/disable interrupts over a short period of time due to an app
> that's only periodically using vblank interrupts.
>
> So it would probably be best to make the 5*DRM_HZ into its own define,
> DRM_VBLANK_IDLE_TIMEOUT or similar, and reduce it by a lot, maybe to as
> low as a few frames; it could even be dynamic based on the refresh rate.

How about triggering it off the vblank interrupt instead of a timer?
So when a vblank happens and no one has asked for a vblank interrupt
since the previous one (or two or whatever), turn it off.

--Andy

>
> --
> Jesse Barnes, Intel Open Source Technology Center
>