[PATCH] reduce useless changes on APM battery.remaining_time
Richard Hughes
hughsient at gmail.com
Sun May 7 01:52:52 PDT 2006
On Sat, 2006-05-06 at 12:07 +0200, Danny Kukawka wrote:
> On Friday 05 May 2006 18:17, Richard Hughes wrote:
> > On Fri, 2006-05-05 at 17:29 +0200, Danny Kukawka wrote:
> > > If there is a application using hal and listen to the change (of the
> > > property)
> > > ever two seconds, followed by do something via dbus (e.g. ask hal or
> > > powersaved for some information) this can result in a high load of
> > > dbus (see
> > > e.g. https://bugzilla.novell.com/show_bug.cgi?id=157905).
> >
> > I get:
> >
> > You are not authorized to access bug #157905. To see this bug, you must
> > first log in to an account with the appropriate permissions.
>
> Okay, you need a account and the related permissions. I remove the link from
> the code and changelog before commit.
>
> > Could you post a few more details pls, thanks.
>
> First it's useless to change the value every 2 seconds because the returned
> value from poll /proc/apm is always changing (in the most cases plus some
> minutes and with the next poll minus several minutes) and not really
> trustable.
With apm you don't get rate (unless you compute it manually), so we have
to trust this value.
> If you e.g. listen with KPowersave (or a other tool) via e.g. powersave or
> directly for this key (if the machine run on battery), you get every 2
> seconds a 'signal' from HAL about changed value of battery.remaining_time. If
> you in this case e.g. check several keys from HAL or e.g. via powersave
> (battery information) you get always (tested on serveral machines) a process
> load between 5 and 25 % for the dbus daemon process.
Surely this is a bug in KPowersave? In g-p-m we cache the values
per-device and then use those cached values to compute the per-system
values.
This avoids having to do lots of non-required lookups every time a key
changes.
This is no different on my laptop with ACPI -- when discharging I get a
few keys changing every couple of seconds, which is great for me as it
makes the data logging aspect of g-p-m feel really snappy and
responsive.
> This is maybe also a problem in DBUS or the dbus-qt bindings, but in fact we
> don't need to change this key every 2 seconds if the value jumps with each
> change forward/backward. This is IMO only confusing programms using this
> information.
Erm, seems like it's only confusing KPowersave...
I would rather this patch not be applied.
Richard.
More information about the hal
mailing list