On Thu, 9 Dec 2010 12:47:52 -0500 Andrew Lutomirski <l...@mit.edu> wrote:
> On Thu, Dec 9, 2010 at 12:20 PM, Jesse Barnes <jbar...@virtuousgeek.org> > wrote: > > On Wed, 8 Dec 2010 13:33:20 -0500 > > Andrew Lutomirski <l...@mit.edu> wrote: > > > >> On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski <l...@mit.edu> wrote: > >> > On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson <ch...@chris-wilson.co.uk> > >> > wrote: > >> >> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski <l...@mit.edu> > >> >> wrote: > >> >>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski <l...@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 <l...@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. -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
