Reduce polling in mythwelcome

[anonymous]

According to powertop, mythwelcome wakes up over 100 times/second.

Reducing this (presumable) polling in mythwelcome would improve performance of other tasks on that system as well as reduce power consumption - if mythwelcome is running, the system is likely not doing anything a good portion of the time.

[candrews@…]

Any ideas on if someone will do this?

I could be convinced to throw some money at this problem, if that would help.

[Stuart Auchterlonie]

Replying to candrews@integralblue.com:

Any ideas on if someone will do this?

Probably.

I could be convinced to throw some money at this problem, if that would help.

No that would *NOT* help.

We develop this in our spare time, we fix tickets when we get a chance. This ticket has only been here for 1 week. That's pretty short. If you want it fixed quicker, feel free to create a patch and add it to the ticket, otherwise, you are just going to have to wait until somebody steps up to do. Heck I probably will, just "Real Life" (TM) is busy.

[paulh]

First of all let me say I'm all for anything that saves power... and money :-). I wrote MythWelcome? and MythShutdown? to make it easier and more user friendly for those people who were concerned so they could set Myth to shutdown when it was idle and that is of cause the best way to save power. I'm not convinced there is anything that needs to be fixed? On my system MythWelcome? is using virtually no cpu (less than 0.1%) and my Athlon X2 seems to stay running at it's lowest speed supported while MythWelcome? is running but that is based on average load I believe and it looks like powertop produces much more fine grained analyse of things.

Also there is nothing being polled in MythWelcome? as such. There are 3 timers that update things. One fires every 30 seconds, one every 15 seconds and one every second. I've no idea how Qt implements these timers or if it could be causing the polling you are seeing. Apart from that MythWelcome? doesn't actually do a great deal.

The first thing I would try is to disable the timers to see if it makes any difference. If it does then there may be a way to use just one timer and reduce the frequency it fires but depending on how Qt implements things it may not make any difference.

I don't have an Intel cpu so cannot verify your results and have no way to test things to see if it improves anything. If you can compile your own stuff and want to try a few things out let me know and maybe we can work together.

[Janne Grunau]

One cause is the select() timeout in mythsocket.cpp around line 740.

The other reasons seems be another select() timeout in the QApplication event loop.

[candrews@…]

I'm very familiar with the potential downsides of donation based development, or bounties on productivity, but I figured I would toss the idea out there regardless. I really enjoy MythTV, and I see it as a extremely important Free Software project - it just seems that I haven't paid my dues. I wish I had more time to create the patch myself... money I have a bit of, time I have virtually none of, unfortunately. In any case, I didn't mean to create undo pressure by commenting on a ticket that I myself opened a week ago - pressure wasn't my intent. Thanks for all the great work, I'll try allocate time instead to work on this.

[drees76@…]

I entered a bit more info in the (now closed) ticket #3800 - there are more numbers regarding how often mythwelcome and mythbackend wake up when idle.

The select timeout in mythsocket.cpp looks to be a big offender, that will cause any application which uses it to wake up at least 100 times a second (default select timeout is 10k usec). Is there any known reason that can't be made larger or infinite?

If I'm reading the code right it seems that the timeout could be made infinite (replace &timeval with NULL on line 743) without drawback thanks to the WakeReadyReadThread? function.

I'll attach a patch if anyone wants to see if it totally breaks anything (I won't be able to test for a couple days).

[drees76@…]

This patch should remove the 100Hz wakeups caused by MythSocket? (compile tested only). Should apply to trunk and release-0-20-fixes branch.

[sandeen]

I tried running w/ this patch (ran powertop, built libmyth, stopped everything, copied over original, ldconfig, started everything, ran powertop again) and didn't see any difference:

before:

Wakeups-from-idle per second : 147.2    interval: 15.0s
no ACPI power usage estimate available
Top causes for wakeups:
  27.4% ( 80.7)      mythfrontend : schedule_timeout (process_timeout) 
  21.4% ( 62.9)       <interrupt> : ivtv0 
  20.6% ( 60.5)       <interrupt> : CMI8738-MC8, nvidia 
   9.8% ( 28.9)       mythbackend : futex_wait (hrtimer_wakeup) 

after:

Wakeups-from-idle per second : 147.8    interval: 15.0s
no ACPI power usage estimate available
Top causes for wakeups:
  27.3% ( 80.8)      mythfrontend : schedule_timeout (process_timeout) 
  21.2% ( 62.8)       <interrupt> : ivtv0 
  20.5% ( 60.6)       <interrupt> : CMI8738-MC8, nvidia 
   9.7% ( 28.7)       mythbackend : futex_wait (hrtimer_wakeup) 

but feel free to double check my results :)

[candrews@…]

I just applied this patch, too.

before:

Wakeups-from-idle per second : 517.9    interval: 10.0s                                                                                                                     


Top causes for wakeups:
  40.0% (145.5)       mythwelcome : schedule_timeout (process_timeout) 
  20.8% ( 75.8)       mythbackend : schedule_timeout (process_timeout) 
  13.9% ( 50.6)       <interrupt> : wlan0, nvidia 
   7.2% ( 26.3)       <interrupt> : eth0 
   4.5% ( 16.5)       mythbackend : futex_wait (hrtimer_wakeup) 

After:

Wakeups-from-idle per second : 369.0    interval: 5.0s                                                                                                                      


Top causes for wakeups:
  26.9% ( 72.4)       mythwelcome : schedule_timeout (process_timeout) 
  21.1% ( 57.0)       <interrupt> : wlan0, nvidia 
  19.5% ( 52.6)       <interrupt> : eth0 
   8.5% ( 23.0)       <interrupt> : libata 
   6.2% ( 16.6)       mythbackend : futex_wait (hrtimer_wakeup) 

It seems that the patch cut the mythwelcome wakeups in half (AWESOME!) but didn't affect the backend.

Is there a drawback to this patch? Or should this be merged? If if it doesn't affect wakeups, it seems that this approach is cleaner, and should be merged anyways.

Thanks!

[anonymous]

I just applied strace to mythwelcome, and this select is called many many times:

read(3, 0x9bba34, 4096)                 = -1 EAGAIN (Resource temporarily unavailable)
select(16, [3 15], [], [], {0, 12129})  = 0 (Timeout)

I cannot figure out where in mythtv this call is made! Can someone point me in the right direction?

[drees76@…]

Replying to sandeen:
I wonder why you didn't see any improvement, but candrews did? Your before wakeups look pretty low compared to what candrews reported and what I've seen.

Replying to candrews@integralblue.com:
It appears that the patch (which I still haven't actually tested myself!) reduced wakeups for both the frontend (145->75) and backend (75-16) which I'm glad to see. Why did you not think it helped the backend? Have you noticed any bugs from running the patch?

Replying to anonymous:
Are you seeing those select timeouts with or without the patch applied? To dig in deeper, you'll likely need to get the debugger out or debugging in some other means.

[candrews@…]

Actually, I'm the anonymous guy, too.

According to powertop, the backend's polling rate stayed the same at ~16.5/sec on my computer. However, it helped in your setup (as it seems it did!) then that's even better!

I've been running the patch since I applied it on a backend/frontend combo, and on a frontend only. I haven't noticed any bugs, and I've been using both to watch and record tv, do live tv, watch videos, etc.

As for the strace, that was taken with the patch applied. I'm presently trying to figure out how to use gdb to figure out where in the code those selects are taking place, but not being a C programmer or someone who has ever used gdb is making that difficult :-)

Thanks again

[drees76@…]

Replying to candrews@integralblue.com:

According to powertop, the backend's polling rate stayed the same at ~16.5/sec on my computer. However, it helped in your setup (as it seems it did!) then that's even better!

You'll notice in your "before" mythbackend shows up twice, once with 75 wu/s (schedule_timeout) and once with 16 wu/s (futex_wait). Your "after" plot eliminates the mythbackend schedule_timeout wakeups completely which is expected from the patch.

The mythbackend futex_wait wakeups are coming from somewhere else.

I've been running the patch since I applied it on a backend/frontend combo, and on a frontend only. I haven't noticed any bugs, and I've been using both to watch and record tv, do live tv, watch videos, etc.

Great! That's what I expected. Hopefully the devs can push this patch upstream!

As for the strace, that was taken with the patch applied. I'm presently trying to figure out how to use gdb to figure out where in the code those selects are taking place, but not being a C programmer or someone who has ever used gdb is making that difficult :-)

The other way is to simply read the code and look for places where polling out timeouts are used, but without being a C/C++ or a programmer at all makes it a bit difficult. :-)

I haven't used gdb in a while myself, but what needs to be done is to attach the process to the debugger and then print out a stack trace of all the running threads. It should be apparent what threads are doing the polling.

[candrews@…]

I recompiled QT and myth with debug symbols and all that fun stuff (that takes a while!). Here's the backtrace:

#0  0x000000346e2ccfb2 in select () from /lib/libc.so.6
#1  0x00002aff23a36ec3 in QEventLoop::processEvents (this=0xb23a20, flags=4) at kernel/qeventloop_x11.cpp:291
#2  0x00002aff23ab8dbf in QEventLoop::enterLoop (this=0xb23a20) at kernel/qeventloop.cpp:198
#3  0x00002aff23a9c0d4 in QApplication::enter_loop (this=0x7fff8740d580) at kernel/qapplication.cpp:2793
#4  0x000000393938ab76 in MythDialog::exec () from /usr/lib/libmyth-0.20.so.0
#5  0x0000000000415eac in ?? ()
#6  0x000000000040d302 in ?? ()
#7  0x000000346e21db74 in __libc_start_main () from /lib/libc.so.6
#8  0x000000000040c749 in ?? ()
#9  0x00007fff8740d828 in ?? ()
#10 0x0000000000000000 in ?? ()

I don't know why I'm not getting a source file and line number on line 4, so I'm going to recompile myth again. Does this help anyone figure out what it is? Also, any ideas why I'm not getting any info on lines 5 and 6 (they may be from libc...)

[candrews@…]

Recompiling yielded a better backtrace:

#0  0x000000346e2ccfb2 in select () from /lib/libc.so.6
#1  0x000000323eb7fec3 in QEventLoop::processEvents (this=0xb35650, flags=4)
    at kernel/qeventloop_x11.cpp:291
#2  0x000000323ec01dbf in QEventLoop::enterLoop (this=0xb35650)
    at kernel/qeventloop.cpp:198
#3  0x000000323ebe50d4 in QApplication::enter_loop (this=0x7fff34361490)
    at kernel/qapplication.cpp:2793
#4  0x00000032427d99c5 in MythDialog::exec (this=0xb38020)
    at mythdialogs.cpp:152
#5  0x0000000000415cc1 in WelcomeDialog::exec (this=0xb38020)
    at welcomedialog.cpp:105
#6  0x000000000040f4e2 in main (argc=1, argv=0x7fff34361718) at main.cpp:100
#7  0x000000346e21db74 in __libc_start_main () from /lib/libc.so.6
#8  0x000000000040e7a9 in _start ()

On line 4, the offending code is: qApp->enter_loop(); Line 5 is: return MythDialog::exec();

Neither of those is an obvious problem. It seems the issue is with QT (but not being a QT programmer, I don't know). So... what is the purpose of qApp->enter_loop();, and could that be the polling source?

[drees76@…]

What's interesting is that according to the QT documentation, enter_loop has been obsoleted/deprecated for some time: ​http://doc.trolltech.com/3.1/qapplication.html#enter_loop

But I'm not a QT dev, either.

[drees76@…]

I finally got around to applying the patch to my 0.20.2 system. I see the same results as candrews with no bad effects. Here's a summary of what happens on my frontend+backend system:

When sitting in mythwelcome, mythfrontend not running:

Before: mythwelcome: 175 wakeups/s, mythbackend: 120 wakeups/s
After: mythwelcome: 70 wakeups/s, mythbackend: 20 wakeups/s

After firing up mythfrontend (mythwelcome still running):

Before: mythwelcome: 100 wakeups/s, mythfrontend: 240 wakeups/s, mythbackend: 120 wakeups/s
After: mythwelcome: 0 wakeups/s, mythfrontend: 140 wakeups/s, mythbackend: 20 wakeups/s

This basically cuts the number of wakeups a second from about 600 to 300 when mythfrontend isn't running and from 800 to 400 when mythfrontend is running which is HUGE.

I would like to see the simple mythsocket patch get applied, I have a feeling that the QT issue will be more difficult to address.

[anonymous]

I posted to the mailing list, no replies (yet)

Just wanted to keep the link here in case anyone runs across this ticket. ​http://mythtv.org/pipermail/mythtv-dev/2007-October/057740.html

[paulh]

I'll give this patch a try over the next few days and if there are no problems it will probably get committed next weekend.

[paulh]

(In [14712]) Prevent MythSocket?'s readyread thread from needlessly waking up 100 times per second. Helps to reduce power consumption.

Patch by drees76 (at) gmail.com. Fixes #3757.

[drees76@…]

Thanks Paul! Would it be possible to apply the patch to the release-0-20-fixes branch as well?

[paulh]

(In [14798]) Merge [14712] from trunk.

Prevent MythSocket?'s readyread thread from needlessly waking up 100 times per second. Helps to reduce power consumption.

Refs #3757.

[Riz]

I've attached a patch that reduces mythwelcome's wakeups from its current 72 wakeups per second to 4 wakeups per second.

To reduce the wakeups, Qts enterLoop function has to be avoided.

The same problem occurs in MythDialog?, which could also do with replacing.

[paulh]

(In [15206]) This further reduces mythwelcome's wakeups from its current 72 wakeups per second to 4 wakeups per second. Helps to reduce power consumption.

Patch by Riz. Closes #3757.

[drees76@…]

Awesome, it looks like the patch applies to the 0.20 branch, will you apply it there, too?