[Psi-Devel] Psi and power consumption

0 views
Skip to first unread message

Dmitry Nezhevenko

unread,
Sep 4, 2008, 1:35:12 PM9/4/08
to Psi Development
Hi. Currently I'm trying to find, why Psi cause CPU to wake up so much
times. It takes second place in powertop "rating". (After Xorg) with no
reason.

Here is strace output:

read(7, 0x8763784, 4096) = -1 EAGAIN (Resource temporarily unavailable)

poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN},
{fd=9, events=POLLIN}, {fd=14, events=POLLIN}, {fd=15, events=POLLIN}], 6, 94)
= 0 (Timeout)

clock_gettime(CLOCK_MONOTONIC, {4443, 172149150}) = 0
read(7, 0x8763784, 4096) = -1 EAGAIN (Resource temporarily unavailable)
clock_gettime(CLOCK_MONOTONIC, {4443, 172335150}) = 0
clock_gettime(CLOCK_MONOTONIC, {4443, 172431510}) = 0
clock_gettime(CLOCK_MONOTONIC, {4443, 172522950}) = 0
read(7, 0x8763784, 4096) = -1 EAGAIN (Resource temporarily unavailable)

poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN},
{fd=9, events=POLLIN}, {fd=14, events=POLLIN}, {fd=15, events=POLLIN}], 6, 95

After this I've recompiled Psi with debug symbols and launched it under
gdb. After starting and going to "idle" I've added break to 'poll()' call.
And here is a stacktrace:

#0 0xb66fec76 in poll () from /lib/i686/cmov/libc.so.6
#1 0xb64809d2 in ?? () from /usr/lib/libglib-2.0.so.0
#2 0x08e8dee8 in ?? ()
#3 0x00000006 in ?? ()
#4 0xb6480d01 in g_main_context_iteration () from
/usr/lib/libglib-2.0.so.0
#5 0xb6a14b78 in QEventDispatcherGlib::processEvents () from
/usr/lib/libQtCore.so.4
#6 0xb6da2415 in ?? () from /usr/lib/libQtGui.so.4
#7 0xb69e8c5a in QEventLoop::processEvents () from
/usr/lib/libQtCore.so.4
#8 0xb69e8e1a in QEventLoop::exec () from /usr/lib/libQtCore.so.4
#9 0xb69eb4c5 in QCoreApplication::exec () from /usr/lib/libQtCore.so.4
#10 0xb6d094e7 in QApplication::exec () from /usr/lib/libQtGui.so.4
#11 0x084caee0 in main (argc=1, argv=0xbf9e4c44) at main.cpp:366

So it looks like this is just Qt event loop. Any ideas why this happens?
There are no such problems with other Qt4 applications.

--
WBR, Dmitry

signature.asc

Michail Pishchagin

unread,
Sep 4, 2008, 6:00:08 PM9/4/08
to Psi Development

On 04.09.2008, at 21:35, Dmitry Nezhevenko wrote:

> Hi. Currently I'm trying to find, why Psi cause CPU to wake up so much
> times. It takes second place in powertop "rating". (After Xorg) with
> no
> reason.

One reason is auto-status-idle checks that happen every second. This
is a bad thing (probably).

Other one seems to be the Qt-Glib compatibility. Try building your own
Qt without Glib and see if it helps.

-Michail
_______________________________________________
Psi-Devel mailing list
Psi-...@lists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affinix.com

Frederik Schwarzer

unread,
Sep 5, 2008, 4:15:48 AM9/5/08
to Psi Development
On Friday 05 September 2008 00:00:08 Michail Pishchagin wrote:

Hi,

> Other one seems to be the Qt-Glib compatibility. Try building your own
> Qt without Glib and see if it helps.

export QT_NO_GLIB=1

After this, Qt should start with disabled GLib-Support.
And it's easier than rebuilding. :)

Regards

Dmitry Nezhevenko

unread,
Sep 5, 2008, 9:01:22 AM9/5/08
to psi-...@lists.affinix.com
On Fri, Sep 05, 2008 at 10:15:48AM +0200, Frederik Schwarzer wrote:
> On Friday 05 September 2008 00:00:08 Michail Pishchagin wrote:
>
> Hi,
>
> > Other one seems to be the Qt-Glib compatibility. Try building your own
> > Qt without Glib and see if it helps.
>
> export QT_NO_GLIB=1
>
> After this, Qt should start with disabled GLib-Support.
> And it's easier than rebuilding. :)
>

Hi. I've already tried this. Issues are not Qt-Glib relative. I've found a
few of them. I'll back to this mailing list later either with patches or
with information, where they are from..

--
WBR, Dmitry

signature.asc

Dmitry Nezhevenko

unread,
Sep 5, 2008, 2:22:49 PM9/5/08
to psi-...@lists.affinix.com
On Fri, Sep 05, 2008 at 02:00:08AM +0400, Michail Pishchagin wrote:
>> Hi. Currently I'm trying to find, why Psi cause CPU to wake up so much
>> times. It takes second place in powertop "rating". (After Xorg) with
>> no
>> reason.
>
> One reason is auto-status-idle checks that happen every second. This is a
> bad thing (probably).
>

Currently I will share found problems. Maybe devs have some ideas how to
workaround/fix them correctly.

All founded issues are caused by using timers with too small interval.
Described below timers are started during psi startup and never stopped.
Maybe devs have some ideas how to workaround/fix them.

1. Autostatus timer, as noticed by Michail.

Interval=1000. As for me it's not so important to have so big precision
here. IMHO something around 10-30 seconds should be enough. I've set it to
5 minutes.

2. FileTuneController timer.

Interval=3000. There is no way to disable it at startup time. It should
be possible to build psi without USE_PEP however I haven't found a way to
do this. Later tools/tunecontroller/plugins/psifile/psifilecontroller.cpp
change timer interval to 10000 msec. Since I don't use PEP, just disabling
this timer is easiest solution.

3. Some animation timer at contactview.cpp.

Interval=600. As far as I understand from code, this is blinking
notification about contact status changes. Generally this timer should be
turned off when there are no nicks to blink. I will try to fix it too. For
now I've just commented start() of this timer

4. Icon animation timer at tools/iconset/anim.cpp

Interval=100. This is the most problematic part IMHO. It's cause of 10
wakeups per second. Disabling this timer causes disappearing of animation
during initial connection to jabber server.

5. MetAlertIcon timer

Interval=600. This is about "Animation" option in configuration. Since
I don't use this animation at all, it was safe to just disable startup of
this timer.

After disabling all of these timers disconnected PSI never wakeup CPU from
idle.

Here is patch that reduce power consumption to almost zero :)
http://inhex.net/dion/psi/10_reduce_power_consumption.diff

There is still one background timer exists (autostatus one), but it's
wakeup interval is 5 minutes.

Yes, patch is ugly, but maybe it will be useful for laptop users, that
prefers longer battery life instead of some fancy UI effects :)

--
WBR, Dmitry

signature.asc

Norman Rasmussen

unread,
Sep 6, 2008, 7:23:44 AM9/6/08
to Psi Development
On Fri, Sep 5, 2008 at 8:22 PM, Dmitry Nezhevenko <di...@inhex.net> wrote:
Currently I will share found problems. Maybe devs have some ideas how to
workaround/fix them correctly.

All founded issues are caused by using timers with too small interval.

One of the other popular tricks, is to make sure that the timers all fire at the start of the second (i.e. when time.milliseconds == 0).  This way you can synchronize many apps all waking up at the same time, and share the cost of that operation.

--
- Norman Rasmussen
- Email: nor...@rasmussen.co.za
- Home page: http://norman.rasmussen.co.za/

Remko Tronçon

unread,
Sep 11, 2008, 9:24:46 PM9/11/08
to Psi Development
> Currently I will share found problems. Maybe devs have some ideas how to
> workaround/fix them correctly.

Thanks. These should be flysprayed separately, and fixed for 0.13.
Could you (or anyone else) do this? The patch doesn't need to be split
or attached or anything, we'll fix it ourselves.

> 1. Autostatus timer, as noticed by Michail.
> Interval=1000. As for me it's not so important to have so big precision
> here. IMHO something around 10-30 seconds should be enough. I've set it to
> 5 minutes.

+1.

> 2. FileTuneController timer.

Odd, I would have guessed there was a way to disable the
filetunecontroller. Again, +1 on making it possible to disable
filetunecontroller.

> 3. Some animation timer at contactview.cpp.

Ouch. This should not be enabled when there's no animation indeed.

> 4. Icon animation timer at tools/iconset/anim.cpp

Ouch^2. Should be fixed ASAP as well.

> 5. MetAlertIcon timer

And another ouch.

Remko Tronçon

unread,
Sep 11, 2008, 9:25:35 PM9/11/08
to Psi Development
> Could you (or anyone else) do this?

I meant flyspraying of course, although actually fixing it properly is
also welcome ;-)

cheers,
Remko

Reply all
Reply to author
Forward
0 new messages