Openmoko Bug #2091: batget polls lots too often
Openmoko Public Trac
bugs at docs.openmoko.org
Tue Oct 28 04:52:53 CET 2008
#2091: batget polls lots too often
-------------------------------+--------------------------------------------
Reporter: Viddy | Owner: openmoko-devel
Type: task | Status: new
Priority: lowest | Milestone: FSO
Component: unknown | Version: FSO-MS2
Severity: trivial | Resolution:
Keywords: batget,polling | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: |
-------------------------------+--------------------------------------------
Changes (by raster):
* priority: normal => lowest
* type: defect => task
* severity: normal => trivial
Comment:
first. 1. the default config for e (upstream) is 32 "ticks" (8 ticks per
second) between polls. thats every 4 seconds. that is less waking up than
almost anything else around on the system. second - it's a config option
in the battery module config - increase the # of ticks between checks
there is a gui for it. 2. you cannot use d/inotify on sysfs - you can't
get change events. it doesn't work. if you could - i would have already. i
use it where appropriate and possible already. 3. - there have been lots
of bugs with emitting events on the uevent file for the battery when
plugging/unplugging power and battery so poll time is "often enough" so
that u'll catch a change (like plug in power and start charging) with a
poll rather than a uevent - i don't know if this is fixed these days as
the polling covers it up mostly. just to expand you can get events - but
the event reports "ac plugged in" but battery wont report its charging for
an arbitrary amount of time after so you have to poll to find this out. or
that was the case last time i looked and was working on this code. 4. if
the screen is blanked u likely want to be going to sleep soon anyway
(suspend) so until zero-clock rolls around and all userspace stuff that
polls needs to be aware of this - it's not work the effort as you have a
problem of not having suspended, rather than there being occasional
polling. if the system is not idle (eg playing music or making a call)
while blanked, then you are constantly awake and consuming cycles anyway
so it doesn't matter. the poll overhead is nigh zero except for kernel ->
device overhead. 5. the battery meter is not a 4 bar limit - that is
merely the theme that om wanted that reduces accuracy. reality is that the
battery reports full detail and the batget abstraction will always report
a value from 0 to 100 for battery then the gadget and ultimately theme are
responsible for displaying it however the like (by putting up a group of
chickens and the more chickens you have, the more power, or by color
(green, yellow, red) or a dial, or... the ui designer entirely decides
that. batget/code know nothing of their intentions and are just there to
feed the current state of the machine :). the battery itself and other
themes display full accuracy (eg e17(illume)'s default theme), so you
can't calculate when to poll as power drain may be variable and the
theme/ui abstracts the display. 6. do some actual power measurements. kill
batget then run it by hand:
/usr/lib/enlightenment/modules/battery/linux-*/batget X
where X is ticks. there are 8 ticks per second. the default is 32. try it
and actually do power drain measurements (run a idle system for lets say
10 minutes and calculate battery drain at the end of it). do it while
running batget @ 32 ticks and with batget off. if you can show measurable
differences (that are not entropy - so u'll have to run the test multiple
times) it'd be maaaaybe worth a bit more code and effort - but really, it
isn't. my bet is that you will not show any measurable difference.
remember - i really paid attention to this when writing the code. it goes
to effort to minimise what it opens when it polls and how often it does
and allows it to be configured. i know about all the details about power
consumption, wakeups, (i've checked with powertop before). batget HAS to
poll (has no choice) and even have a generic mechanism to indicate the
polling interval. :)
so here's your challenge. test with batget off. run for a period of time
(10 mins, 30) measure drain (from full), recharge to full then do it again
with batget at 32 ticks, then maybe try it at 128 or 256 or 512 ticks
(make it a power of 2 - it only allows power of 2). if you got a
measurable difference from no batget to 32 ticks. if u see a difference <
5-10% it's probably entropy so u'll need to run the test many times to get
an average.
if you can show real differences - report back here :) because there is
nothing much u can do code-wise to improve this beyond the battery issuing
interrupts via kernel to indicate a change in level, which the battery is
not capable of doing as it literally needs to be polled to get its charge
on the hardware level. so someone will do the polling - if not batget -
it'll be a kernel thread. you just shuffle the problem out of your sight -
but don't remove it or the overhead. what you do add is likely lack of
control and configuration :)
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2091#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
More information about the buglog
mailing list