Bug 152829 - KDE4 (rc1): powertop shows over 100 wakeups per second
Summary: KDE4 (rc1): powertop shows over 100 wakeups per second
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
Depends on:
Reported: 2007-11-24 17:22 UTC by Alan Jenkins
Modified: 2007-12-18 11:55 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:

Powertop output (3.87 KB, text/plain)
2007-11-24 17:23 UTC, Alan Jenkins

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Jenkins 2007-11-24 17:22:06 UTC
Version:            (using KDE KDE 3.96.0)
Installed from:    SuSE RPMs

I took KDE4 RC1 for a spin, using SUSE's one-click install.

I opened the applications I normally use, and ran powertop.  The result showed around 100 wakeups/s.  10 would be a nice target to have, and I've managed lower in the past.
Comment 1 Alan Jenkins 2007-11-24 17:23:08 UTC
Created attachment 22182 [details]
Powertop output
Comment 2 Alan Jenkins 2007-11-24 17:43:28 UTC
I ran powertop for 60s on an idle system.  KDE definitely shouldn't have needed to wake up ~6000 times in that period.

Specifically, KMail, akregator, konsole and konqueror are running at 20 wakeups per second.  I expect theres a common cause for this.

strigidaemon also takes 10 wakeups per second, but I'm not sure if it belongs to  KDE or not.

kwrapper4 is at 1 wakeup/s.  Which is a pity because I've already submitted a patch which fixes this problem for the kde3 version, and in doing so it *adds* the feature  of copying the exit code of the wrapped process.  Thats attached to another bug report.

Plasma and kwin are also both doing just over 1 wakeup/s.  

KDE3's kwin and kdesktop tend to do something similar.  I thought I'd tracked the problem down to startup notifications - found it in the source, restarting the programs concerned  solved the problem, and the wakeups came back if I started a new application. In KDE4 though, I can stop the wakeups by restarting kwin, but I can't get them back again afterwards, so these wakeups may have a different cause.
Comment 3 Maksim Orlovich 2007-11-24 20:21:28 UTC
Is this under a composite manager mode or not? Also, were you using the apps, or idling?
Comment 4 Alan Jenkins 2007-11-25 11:01:21 UTC
It was idle for the entire 60 seconds.  Also amarok was stopped.

I didn't see any translucent windows/menus or wobbly windows.

I'm afraid I'm rather ignorant about composite, and I've only recently installed SuSE.  I'm not sure how to check whether its enabled.

I did attempt to use compiz on KDE3.  I uninstalled xgl which seemed to have been installed by default (after reading the description "highly experimental code" and learning it was no longer necessary), and made sure AIGLX and EXA were enabled.

However, when I tried to run compiz on KDE3, it failed with "No composite extension".  I wasn't really expecting it to work though, since my hardware was blacklisted by compiz when I tried it on Ubuntu Gutsy.
Comment 5 Maksim Orlovich 2007-11-25 18:09:47 UTC
If you don't have a composite extension, then it shouldn't be running.. A way to check is to right click window decoration, chose to configure, and then go to the window effects icon, and see if effects are enabled or not.. Anyway, this is quite weird --- I tested konqueror4 (since that's the part I am involved with), on KDE3, and logged all the timer firings, and it's doing less than one firing per second... Will also test in an entire session, I guess.
Comment 6 Alan Jenkins 2007-11-25 19:29:37 UTC
In a KDE4 session, window manager effects are greyed out; it says I don't have the required extensions.

After what you said I tried running the KDE4 version of konqueror in my KDE3 session, and it was still doing 20 wakeups/s there too.
Comment 7 Alan Jenkins 2007-11-25 20:34:11 UTC
Aha.  I tried a trick I've used successfully before, which is to run it under callgrind for different lengths of time, then drill down and see which timer callbacks get called more in the longer run.

In this case, thats "OxygenStyle::qt_metacall".  A 5s run has 105 calls to it, and a 30s has 592 of them.  Maybe you don't see it because you're using a different style?

Whats odd is that I can drill down further, and see that each call to OxygenStyle::qt_metacall() is also dispatching all the way down the inheritance hierachy, to QObject::qt_metacall().  My intuition says this could only happen if the "metacall" was trying to find a non-existent slot, so it keeps on looking at superclasses trying to find a match until it runs out.  I'd wouldn't have thought you could trick the compiler into doing that though.

The numbers imply that this fruitless search is happening for every call to OxygenStyle::qt_metacall(), and indeed, if I debug a running instance, break on OxygenStyle::qt_metacall(), and single-step it, thats what it does.

BTW, is there a way to decode what this is supposed to do, I'm thinking some way of looking up the value _id=14 below?
#3  0x00002ba95d509516 in OxygenStyle::qt_metacall (this=0x680110,
    _c=QMetaObject::InvokeMetaMethod, _id=14, _a=0x7fff562d7940)

Anyway, heres the full backtrace:

#0  0x00002ba959872208 in QObject::qt_metacall ()
   from /usr/lib64/libQtGui.so.4
#1  0x00002ba959cf9da5 in QStyle::qt_metacall ()
   from /usr/lib64/libQtGui.so.4
#2  0x00002ba959cf9fd5 in QCommonStyle::qt_metacall ()
   from /usr/lib64/libQtGui.so.4
#3  0x00002ba95d509516 in OxygenStyle::qt_metacall (this=0x680110,
    _c=QMetaObject::InvokeMetaMethod, _id=14, _a=0x7fff562d7940)
    at /usr/src/debug/kdebase-runtime-3.96.1/build/kstyles/oxygen/oxygen.moc:67
#4  0x00002ba958d2c9be in QMetaObject::activate ()
   from /usr/lib64/libQtCore.so.4
#5  0x00002ba958d2999c in QObject::event () from /usr/lib64/libQtCore.so.4
#6  0x00002ba95988287b in QApplicationPrivate::notify_helper ()
   from /usr/lib64/libQtGui.so.4
#7  0x00002ba959883e75 in QApplication::notify ()
   from /usr/lib64/libQtGui.so.4
#8  0x00002ba955d904ce in KApplication::notify (this=0x7fff562d8770,
    receiver=0x67f820, event=0x7fff562d8270)
    at /usr/src/debug/kdelibs-3.96.1/kdeui/kernel/kapplication.cpp:319
#9  0x00002ba958d1b760 in QCoreApplication::notifyInternal ()
   from /usr/lib64/libQtCore.so.4
#10 0x00002ba958d3cd2d in QTimerInfoList::activateTimers ()
   from /usr/lib64/libQtCore.so.4
#11 0x00002ba958d3a8ed in timerSourceDispatch ()
   from /usr/lib64/libQtCore.so.4
#12 0x00002ba95c097064 in g_main_context_dispatch ()
   from /usr/lib64/libglib-2.0.so.0
#13 0x00002ba95c09a35d in ?? () from /usr/lib64/libglib-2.0.so.0
#14 0x00002ba95c09a82e in g_main_context_iteration ()
   from /usr/lib64/libglib-2.0.so.0
#15 0x00002ba958d3ac21 in QEventDispatcherGlib::processEvents ()
   from /usr/lib64/libQtCore.so.4
#16 0x00002ba9598f2f2f in QGuiEventDispatcherGlib::processEvents ()
   from /usr/lib64/libQtGui.so.4
#17 0x00002ba958d1af00 in QEventLoop::processEvents ()
   from /usr/lib64/libQtCore.so.4
#18 0x00002ba958d1b01d in QEventLoop::exec () from /usr/lib64/libQtCore.so.4
#19 0x00002ba958d1cf17 in QCoreApplication::exec ()
   from /usr/lib64/libQtCore.so.4
#20 0x00002ba954a8e012 in kdemain (argc=<value optimized out>,
    argv=<value optimized out>)
    at /usr/src/debug/kdebase-3.96.1/apps/konqueror/src/konqmain.cpp:218
#21 0x00002ba95ac3fb54 in __libc_start_main () from /lib64/libc.so.6
#22 0x00000000004008b9 in _start ()

Comment 8 Maksim Orlovich 2007-11-25 21:53:33 UTC
Aha. I was using plastique. Seems like Oxygen's scrollbar animation code is not disabling the timer when not needed. In fact, all of  OxygenStyle::updateProgressPos() is disabled, so it's being useless.

(I was using a different trick: I just modified QTimerInfoList::activateTimers to dump info on destinations)
Comment 9 Camilla Boemann 2007-12-08 19:32:48 UTC
fixed in rev 746337