Thread: [aKregator-devel] [Bug 145961] New: akregator has a high interrupt usage when idle
Brought to you by:
lippel
From: Mark P. <ms...@de...> - 2007-05-25 15:50:36
|
------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=145961 Summary: akregator has a high interrupt usage when idle Product: akregator Version: unspecified Platform: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general AssignedTo: akregator-devel lists sourceforge net ReportedBy: msp debian org Version: 1.2.7 (using KDE 3.5.7, Debian Package 4:3.5.7.dfsg.1-1 (lenny/sid)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.21-1-686 powertop[1] is brining up all sorts of previously unknown issues with Linux power management. Of suprise to me was akregator, sitting idle in my task bar is using around 10%: 10.1% (10.6) akregator : schedule_timeout (process_timeout) This is with seven feeds fetching every 30 mins :-( aRts has gone through a similar exercise[2] [1] http://www.linuxpowertop.org/ [2] http://vir.homelinux.org/blog/index.php?url=archives/41-PowerTOP-and-aRts.html Could be worth a look under the hood of akregator. Mark |
From: Mark P. <ms...@de...> - 2007-05-25 17:24:21
|
------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=145961 ------- Additional Comments From msp debian org 2007-05-25 19:24 ------- Seems to be related to the option: Mark selected article read after XX sec When XX is 0 (the default) interrupt usage is high, I guess it is constantly polling. When disabled, or set to non-zero interrupt usage is non-existant. Short term, the default should be changed to 1 sec (almost no difference in usage), long term the polling loop should be made a little smarter and not poll, but be event driven when the user goes to a new article. Mark |
From: Eckhart Wör. <kd...@ew...> - 2007-05-26 22:37:23
|
------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=145961 ------- Additional Comments From kde ewsoftware de 2007-05-27 00:37 ------- I tried to reproduce the bug (Debian unstable packages), but wasn't able to. ~30 feeds, marking as read after 0 seconds. Akregator only appears sometimes, with < 0,5 wake-ups/s. Could you please provide more details, e.g. what size does your archive have, do wake-ups increase over time, steps to reproduce? |
From: Frank O. <fra...@kd...> - 2007-05-29 07:10:41
|
------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=145961 ------- Additional Comments From frank.osterfeld kdemail net 2007-05-29 09:10 ------- > Short term, the default should be changed to 1 sec (almost no difference in usage) Of course there is a big difference in usage, when navigating through the articles with the cursor keys, the articles selected for < 1 sec are not marked read anymore. >, long term the polling loop should be made a little smarter and not poll, but > be event driven when the user goes to a new article. There is no polling needed for any related functionality in Akregator. But there might be a timer incorrectly set up, firing constantly instead of once. (the lower the n, the more frequent are the wakeups) I will investigate. |
From: Alan J. <aj...@st...> - 2007-10-01 09:48:44
|
------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=145961 aj504 student cs york ac uk changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alan-jenkins tuffmail co uk ------- Additional Comments From aj504 student cs york ac uk 2007-10-01 11:48 ------- BTW. I use akregator and I see a constant ~0.5 wakeups/s. I've been using callgrind to track it down, by comparing call counts for akregator running for different amounts of time (using --nofork --hide-mainwindow). I've traced it to Akregator::Backend::StorageMK4Impl::slotCommit. I expect to post a separate bug with a patch. I thought it might help if I mentioned it. a) Fixing the lesser problem might make easier to isolate this bug. b) I can summarize the timers I found and dismissed; it's possible one of these is responsible for this bug. c) The same brute force I used might help find this bug. I'm using "valgrind --tool=callgrind akregator --nofork --hide-mainwindow", and kcachegrind to view the output. I isolated the ~0.5 wakeup/s issue by comparing the output for two akregators running for different lengths of time, and comparing call counts for the callees of QObject::activate_signal(QConnectionList*, QUObject*). (Against akregator 3.5.6-0ubuntu6) and checking the call count for the method called by the timer. First column is # of times the timer fired during a test run. "start/stop" means that the timer is not expected to run continually. 1 akregator_part.h:213: QTimer* m_autosaveTimer; // 5 minutes slotSaveFeedList() 1 akregator_view.h:328: QTimer *m_fetchTimer; // 1 minute slotDoIntervalFetches() 0 akregator_view.h:329: QTimer* m_expiryTimer; // 1 hour slotDeleteExpiredArticles() 0 akregator_view.h:330: QTimer *m_markReadTimer; // Settings::markReadDelay() seconds, start/stop, slotSetCurrentArticleReadDelayed() /* one-off (during startup) */ 1 akregator_view.cpp:369: QTimer::singleShot(1000, this, SLOT(slotDeleteExpiredArticles()) ); 1 / akregator_view.cpp:370: QTimer::singleShot(0, this, SLOT(delayedInit())); \ akregator_view.cpp:381: QTimer::singleShot(500, this, SLOT(delayedInit())); 0 feedlistview.cpp:70: QTimer autoopentimer; // 750ms, start/stop openFolder() 0 searchbar.cpp:57: QTimer timer; // 200ms, start/stop, slotActivateSearch() /* 2 seconds, start/stop, batches new article notifications when they come in */ 0 notificationmanager.cpp:70: QTimer::singleShot(m_checkInterval, this, SLOT(slotIntervalCheck())); 0 notificationmanager.cpp:126: QTimer::singleShot(m_checkInterval, this, SLOT(slotIntervalCheck())); |