On Thu, 9 Dec 2010 13:32:04 -0500 Andrew Lutomirski <[email protected]> wrote:
> 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. That could work ok, but it would add a little more code to the interrupt handler that isn't time critical; we'd also have to be careful of the locking. If you want to submit a patch to do that it's fine with me, but it should be separate from increasing the timeout. Thanks, -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
