Powertop reports much more interrupts connected with graphics, that on 2.4.2 driver. On idle it is about 60-100 (on 2.4.2 it's less then 10), and over 1000 when i'm actively using desktop. It costs almost 2W of power on battery. I'm using KDE 4.1.2, on gentoo system (x86_64). Hardware: Lenovo T400. Because of gentoo patch, kms is disabled by default. Powertop output: 65.0% (2674.8) <interrupt> : ahci, uhci_hcd:usb5, i915@pci:0000:00:02.0 21.2% (872.2) <kernel IPI> : Rescheduling interrupts 3.3% (136.3) amarok : schedule_timeout (process_timeout) 2.4% ( 99.6) knotify4 : schedule_timeout (process_timeout) 1.8% ( 74.0) <interrupt> : extra timer interrupt 1.7% ( 70.0) USB device 1-1 : Comfort Optical Mouse 1000 (Microsoft) 1.7% ( 69.9) <interrupt> : pciehp, uhci_hcd:usb1 1.5% ( 63.6) <interrupt> : HDA Intel, uhci_hcd:usb6, iwlagn 0.5% ( 21.0) X : do_setitimer (it_real_fn) 0.3% ( 14.2) firefox : futex_wait (hrtimer_wakeup) 0.2% ( 8.0) <kernel module> : usb_hcd_poll_rh_status (rh_timer_func) 0.1% ( 4.2) plasma : schedule_timeout (process_timeout) 0.1% ( 2.3) kwin : schedule_timeout (process_timeout) 0.0% ( 1.0) <kernel core> : enqueue_task_rt (sched_rt_period_timer) 0.0% ( 0.8) <interrupt> : PS/2 keyboard/mouse/touchpad 0.0% ( 0.8) konsole : schedule_timeout (process_timeout) 0.0% ( 0.5) iwlagn : ieee80211_sta_work (ieee80211_sta_timer) 0.0% ( 0.5) hald-addon-stor : schedule_timeout (process_timeout) 0.0% ( 0.5) wpa_cli : schedule_timeout (process_timeout) 0.0% ( 0.4) kadu : schedule_timeout (process_timeout) 0.0% ( 0.3) X : schedule_timeout (process_timeout) 0.0% ( 0.3) <kernel module> : neigh_table_init_no_netlink (neigh_periodic_timer) 0.0% ( 0.3) kded4 : schedule_timeout (process_timeout) 0.0% ( 0.2) klauncher : schedule_timeout (process_timeout) 0.0% ( 0.2) knotify4 : futex_wait (hrtimer_wakeup) 0.0% ( 0.2) amarok : futex_wait (hrtimer_wakeup) 0.0% ( 0.2) li : schedule_timeout (process_timeout) 0.0% ( 0.2) init : schedule_timeout (process_timeout) 0.0% ( 0.2) pdflush : do_journal_end (delayed_work_timer_fn) 0.0% ( 0.1) <kernel module> : sta_info_start (sta_info_cleanup)
Created attachment 20150 [details] my config
Created attachment 20151 [details] my dmesg
What if you update your kernel to 2.6.28-rc, or better yet the one from git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git (branch drm-intel-next). Those have interrupt mitigation code that should quiet things down when idle.
Hi Jesse, thanks for quick respond. I checked 2.6.28-rc4 and drm-intel-next as you suggested, but there are still a lot of i915 interrupts. I don't know is it possible, but it looks like there's a little less of them, at most 1200 when i'm using desktop. And I had to change my my xorg.conf, without these changes my xorg hanged. But I noticed huge performance boost - 1200fps in glxgears (currently about 300). Good job!
Created attachment 20214 [details] My new xorg.conf
The main thing to be sure of is that when your desktop is idle (no drawing is going on, even in dock applets) you don't see any interrupts. It may take a few seconds for them to stop coming after you become idle (there's a timer in the kernel), but after that you shouldn't see i915 interrupts. Keep in mind though that i915 is shared with your disk controller and one of your USB ports on your machine, so interrupts on those devices. You'll need to monitor /proc/interrupts from an ssh session or something though, since doing it in an xterm would cause more interrupts. What changes did you make to your xorg.conf to avoid hangs?
I'm comparing results from tests with 2.5.0 and 2.4.2 version of driver. Now i'm using 2.4.2, and after few minutes of idle i see 0.7 interrupts: 0.5% ( 0.7) <interrupt> : ahci, uhci_hcd:usb6, i915@pci:0000:00:02.0 When I use 2.5.0, with exactly the same way of testing, i see 8 interrupts (it is indeed much better than 60-100!). But biggest diffrence is when i start firefox, and browsing. I can't break 500 interrupts on 2.4.2, but on 2.5.0 it happens almost immediately, and as i wrote, reach over 1000 interrupts. Maybe it should be this way? About those changes. Earlier i had only device, monitor and screen section, and i let xorg configure itself. Now i'm using config generated with xorgconfig. I can try to ssh on my machine after while and write about results with both drivers if needed.
Yeah, more interrupts during actual usage is expected with 2.5.0. We don't busy wait as much with the CPU, instead we put the X server to sleep and wait for interrupts. This means many more interrupts but also means more CPU sleep time... I'm not sure why you still see 8 interrupts/second with the 2.5.0 driver when idle though; maybe something on your desktop is rendering every now and then?
Hi Jesse. You were right, i had some applets painting on my screen all the time. After i disabled it, i reached 0.2 interrupts/second. Now i'm worried about "extra timer interrupt" problem in 2.6.28-rc, but this is problem with NOHZ as far as i know. Thanks for help!
Thanks for confirming. Yeah there are some NOHZ and/or timer related problems in the kernel these days. If you can reproduce them reliably I'd recommend posting to lkml; developers are having a hard time tracking down those bugs and can probably use more help.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.