process wakeups
Dan Williams
dcbw at redhat.com
Tue Jul 15 16:07:13 UTC 2008
On Tue, 2008-07-15 at 16:57 +0100, Daniel P. Berrange wrote:
> On Tue, Jul 15, 2008 at 11:52:35AM -0400, Dan Williams wrote:
> > On Mon, 2008-07-14 at 14:57 -0700, Ulrich Drepper wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > One of the worst problems wrt energy savings we have today are all the
> > > wakeups processes request. This is not just an issue for laptops, it
> > > relevant everywhere.
> > >
> > > To see the size of the problem run the attached systemtap script. On my
> > > laptop I see the following output (47 secs runtime):
> > >
> > > uid | poll select epoll itimer futex nanosle signal| process
> > > 29799 |15941 7971 0 0 0 0 0| npviewer.bin
> > > 29841 | 253 0 0 0 1531 0 0| thunderbird-bin
> > > 3017 | 447 0 0 0 0 0 0| pulseaudio
> > > 2467 | 76 0 0 0 0 0 0| hald
> > > 2471 | 8 0 0 0 0 0 0| hald-runner
> > > 2620 | 58 0 0 0 0 0 0| NetworkManager
> >
> > While there are probably stupidities in NM, there are also known
> > externally-driven wakeup causes including:
> >
> > 1) until 2.6.27 lands, there's no way to get the rfkill switch
> > state-change events, so NM polls them every 6 seconds _iff_ they exist.
> > Unfortunately, they often exist in HAL even though there are no physical
> > switches on the laptop because the nice rfkill patches haven't landed
> > yet (again, scheduled for 2.6.27)
>
> Ahhh, so that's probably what's causing /usr/libexec/hal-ipw-killswitch-linux
> to be run every 6 seconds, which in turns causes any app connected to DBus
> system bus to be send a signal every 6 seconds and thus causes all the
> hits against libvirtd - and a fair number of other apps in that list too
That's probably the cause, yes.
Is D-Bus signal filtering done client-side or bus-side? I forget. You
do have to explicitly subscribe to most signals (see dbus_bus_add_match)
with libdbus otherwise you won't get them, so maybe a library that
libvirt depends on is asking for the subscription or not properly
limiting its subscription.
Dan
More information about the fedora-devel-list
mailing list