Hi Alex, Alex Murray wrote: > On Wed 28 Mar 2012 15:17:14 CST, Németh Márton wrote: >> Hi Alex, Carlos, Martin, Todd, Benoît and Davyd, >> >> I'm using your gnome applets to monitor the following things on my laptop: >> - CPU temperature (sensors-applet, http://sensors-applet.sourceforge.net/ ) >> - CPU usage (multiload-applet-2) >> - CPU frequency (cpufreq-applet) >> >> My primary goal is to keep the CPU fan quiet as far as possible. This can >> be achieved if the CPU temperature is kept low which depends on the CPU >> usage and on CPU frequency. >> >> Then I run powertop 1.13 ( http://www.lesswatts.org/projects/powertop/ ) >> to see what processes are causing wakeups. I realized that the applets I >> run in order to have an overview on the CPU usage causes additional CPU wakeups. >> >> So I modified the refresh interval of sensors-applet to 5.0s. >> The cpufreq-applet does not have any possibility to reduce the update interval. >> I also modified the default update interval of multiload-applet-2 to 5000ms. >> >> As you can see I can set up two of the applets to wake up the CPU once in >> 5 seconds, but these two alone will wake up the CPU worst case every 2.5 seconds. >> >> I don't know if there is any possibility to synchronize the gnome applets >> so that they wakes up one after the other causing only one wakeup every 5 seconds. >> >> Here is the list of software versions I used: >> >> $ lsb_release -a >> LSB Version: >> core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:cxx-3.0-ia32:cxx-3.0-noarch:cxx-3.1-ia32:cxx-3.1-noarch:cxx-3.2-ia32:cxx-3.2-noarch:desktop-3.1-ia32:desktop-3.1-noarch:desktop-3.2-ia32:desktop-3.2-noarch:graphics-2.0-ia32:graphics-2.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:graphics-3.1-ia32:graphics-3.1-noarch:graphics-3.2-ia32:graphics-3.2-noarch:qt4-3.1-ia32:qt4-3.1-noarch >> Distributor ID: Debian >> Description: Debian GNU/Linux 6.0.4 (squeeze) >> Release: 6.0.4 >> Codename: squeeze >> $ dpkg -l gnome-power-manager gnome-applets sensors-applet >> Desired=Unknown/Install/Remove/Purge/Hold >> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend >> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) >> ||/ Name Version Description >> +++-================================-================================-================================================================================ >> ii gnome-applets 2.30.0-3 Various applets for the GNOME panel - binary files >> ii gnome-power-manager 2.32.0-2 power management tool for the GNOME desktop >> ii sensors-applet 2.2.5-4 Display readings from hardware sensors in your Gnome panel >> >> Regards, >> >> Márton Németh >> > > Hi Márton, > > Thankfully you needn't worry too much about unsynchronised wakeups > since the glib developers already thought of this and there exists the > function g_timeout_add_seconds() [1] which causes the wakeups to occur > in whole second amounts AT whole second intervals - so multiple wakeups > are synchronised for exactly the reason you want. > > sensors-applet already uses this [2] as does cpufreq [3] however it > looks like multiload doesn't [4] - but a simple patch to change this to > the seconds variant shouldn't be too hard and should then allow all 3 > to be in sync (as far as I can tell). > > Cheers > Alex > > [1] > http://developer.gnome.org/glib/2.30/glib-The-Main-Event-Loop.html#g-timeout-add-seconds-full > [2] > http://sensors-applet.git.sourceforge.net/git/gitweb.cgi?p=sensors-applet/sensors-applet;a=blob;f=sensors-applet/sensors-applet.c;h=e9801a05f2be8631c2bfa59ed299e338a7be57c5;hb=HEAD#l1415 > [3] > http://git.gnome.org/browse/gnome-applets/tree/cpufreq/src/cpufreq-monitor.c#n319 > [4] > http://git.gnome.org/browse/gnome-applets/tree/multiload/load-graph.c#n377 Thanks for your quick and into deep description of this question. Reading [1] rises some more questions for me. To summarize: - sensors-applet uses g_timeout_add_seconds() [2], shouldn't it use g_timeout_add_seconds_full()? - cpufreq-monitor uses g_timeout_add_seconds() [3], this has to be replaced with g_timeout_add_seconds_full() - multiload uses g_timeout_add(): if the interval parameter is multiple of 1000ms then the g_timeout_add_seconds_full() can be used. The function g_timeout_add_seconds_full() [1] solves the problem when different applets are required to run at 1000ms intervals. As I can see, however, this does not solve the case when the interval is set up for example to 5000ms. Worst case I can have the following scenario with three applets, each of them is set up to 5000ms refresh time assuming all of them uses g_timeout_add_seconds_full(): t = 0ms: sensors-applet runs t = 1000ms: cpufreq-monitor runs t = 2000ms: multiload runs t = 3000ms: IDLE t = 4000ms: IDLE t = 5000ms: sensors-applet runs t = 6000ms: cpufreq-monitor runs t = 7000ms: multiload runs t = 8000ms: IDLE t = 9000ms: IDLE t = 10000ms: sensors-applet runs ... So in a 10 second interval the system will wake up six times instead of two. This problem leads us to the "gratest common divider" problem [5] in general cases. By the way, do you know about an applet which can query the registered processes which used the g_timeout_add*() functions from glib and show a graph or a text representation when they are due (like above)? This could give a good overview on a given system. Another thing is that in case of the cpufreq-monitor applet, which displays the actual CPU frequency the polling is not the most efficient way displaying this information. Assuming that the "ondemand" CPU frequency scaling governor is active the CPU will only scale up if there is a load on the CPU. This happens when the CPU is active. The frequency downscaling is also happening when the CPU is active. So in the kernel there is an exact place when this happens. I don't know if this kind of information is available for user-space processes, maybe the CPUFreq notifiers [6] can be used for this? [5] http://en.wikipedia.org/wiki/Greatest_common_divisor [6] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cpu-freq/core.txt;hb=HEAD#l43 Regards, Márton Németh -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
