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