On Thu, Dec 9, 2010 at 1:23 PM, Jesse Barnes <[email protected]> wrote: > On Thu, 9 Dec 2010 12:47:52 -0500 > Andrew Lutomirski <[email protected]> wrote: > >> On Thu, Dec 9, 2010 at 12:20 PM, Jesse Barnes <[email protected]> >> wrote: >> > On Wed, 8 Dec 2010 13:33:20 -0500 >> > Andrew Lutomirski <[email protected]> wrote: >> > >> >> On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski <[email protected]> wrote: >> >> > On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson <[email protected]> >> >> > wrote: >> >> >> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski <[email protected]> >> >> >> wrote: >> >> >>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <[email protected]> >> >> >>> 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 <[email protected]> >> >> >> >> 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 > _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
