powerd on XS?

pgf at laptop.org pgf at laptop.org
Fri Apr 17 10:07:38 EDT 2009


martin and i just had a short exchange off-list that we realized
should probably be moved on-list.  here's an edited transcript:

 > To:      Martin Langhoff <martin.langhoff at gmail.com>
 > From:    pgf at laptop.org
 > Subject: Re: Bxl testing report - April 16th 
 > 
 > hi martin --
 > 
 > i've been watching your XS development updates (and
 > applauding, btw :-), and it occurred to me i should remind you
 > about olpc-powerd XS-on-XO.  it might not be the least bit
 > necessary -- you might even get exactly the behavior you want
 > without installing either it or ohmd -- but if you need any kind of
 > power/suspend/screen-dimming/shutdown kinds of management,
 > powerd is far more easily tweaked.  as an example,
 > the other day i realized that on a small server i was setting
 > up on an XO (a home audio server), that it would be convenient
 > to be able to run it on the shelf with lid closed.  it was
 > trivial to add a "remain awake when shut" config option. 
 > another example:  the XS might want a limit how long it runs
 > on batteries without external power -- again, trivial with
 > powerd.  (powerd already performs a critical battery level
 > shutdown, which ohmd lacks.)
 > 
 > paul

....

 > To:      Martin Langhoff <martin.langhoff at gmail.com>
 > From:    pgf at laptop.org
 > Subject: Re: Bxl testing report - April 16th 
 >
 > martin wrote:
 >  > Great idea, thanks for the offer! Remain awake when shut is desirable
 >  > (but was getting that... because I don't have ohmd :-) ) -- and
 >  > shutdown when on low battery is something I really need (so I'll need
 >  > power handling).
 >  > 
 >  > Powerd is written in Python? Some of the questions I'll come asking is:
 > 
 > actually, no -- it's in shell, with two helper daemons in C.  (i pre-date
 > python. ;-)
 > 
 > the three pieces are:
 > 
 >     olpc-kbdshim:  implements support for the "grab" keys on the
 > 	XO keyboard, and rotates the action of the touchpad to
 > 	match rotation of the screen.  what's pertinent here is
 > 	that because it's watching the entire user input stream,
 > 	it also reports user idle and activity states to powred. 
 > 	there are two versions:  the principle version is part of
 > 	HAL, because that makes watching USB keyboards a lot
 > 	easier.  there's a previous, almost identical standalone
 > 	version, however, if you're not using HAL.  (i really
 > 	didn't want to depend on hal, so i wrote that version
 > 	first.  but support for USB input devices forced my hand.)
 > 
 >     olpc-switchd: watches the lid, ebook, and power-button switches,
 > 	and periodically polls (15 second interval) AC and battery status.
 > 
 >     powerd:  it's a big shell loop that watches events that
 > 	arrive via a fifo, and acts on them to manage the idle
 > 	timeouts, watch battery level, etc.  perhaps not useful
 >	for the XS is that it uses rtcwake to allow a sleeping laptop
 >	to wake up in order to either turn off its own display, or to
 >	shutdown completely.
 > 
 >  >  - what's the mem footprint?
 > 
 > i don't think the VSZ/RSS numbers are very useful in this case,
 > since the shell is probably always resident.  if i stop powerd,
 > "free" tells me i get 350K back.  that seems to be reproducible. 
 > same metric with olpc-switchd says roughly 100K.  it's harder to
 > quickly get isolated numbers from olpc-kbdshim because it's
 > started/stopped by hald, but i'd guess it's similar to
 > olpc-switchd.  so call it all 600K, certainly less than 1M, in
 > total.
 > 
 >  >  - how can we minimise it?
 > 
 > the olpc-switchd functionality could be pulled into olpc-kbdshim.  powerd
 > could be rewritten in C (which wouldn't be hard, now that its been
 > prototyped -- just a bit time consuming).
 > 
 > also, i was careful not to write bash-specific code -- i
 > _believe_ powerd will run under dash, for instance.  perhaps not
 > advantageous if bash is already resident, but maybe.
 > 
 >  >  - how can we make sure it's safe to swap the process out if no
 >  > relevant events are triggered?
 > 
 > this sounds like you're doing the swapping manually somehow.  otherwise,
 > i'm not sure i understand why it wouldn't swap in when needed?
 > 
 >  >  - can we turn powerd into logic that gets triggered by kernel events
 >  > (udev, etc) instead of a resident daemon?
 > 
 > well, that's sort of what it is now, at some level.
 > 
 >  > [ Those are the same nasty questions I ask about every bit of sw on
 >  > the XS. It's a tricky space... ]

.....................

 > To:      pgf at laptop.org
 > From:    Martin Langhoff <martin.langhoff at gmail.com>
 > Subject: Re: Bxl testing report - April 16th
 > 
 > On Fri, Apr 17, 2009 at 3:25 PM,  <pgf at laptop.org> wrote:
 > > martin wrote:
 > >  > Great idea, thanks for the offer! Remain awake when shut is desirable
 > >  > (but was getting that... because I don't have ohmd :-) ) -- and
 > >  > shutdown when on low battery is something I really need (so I'll need
 > >  > power handling).
 > >  >
 > >  > Powerd is written in Python? Some of the questions I'll come asking is:
 > >
 > > actually, no -- it's in shell, with two helper daemons in C.  (i pre-date
 > > python.  ;-)
 > 
 > that's great! Then my concerns of multi-meg mem footprint are
 > unfounded. I shall shut up. Should we repost the tech discussion so
 > far to devel@?
 > 
 > > i don't think the VSZ/RSS numbers are very useful in this case,
 > > since the shell is probably always resident.  if i stop it,
 > 
 > Good point. I've found ps_mem.py to be an excellent tool for this...
 > 

thanks for the pointer!

 > > this sounds like you're doing the swapping manually somehow.  otherwise,
 > > i'm not sure i understand why it wouldn't swap in when needed?
 > 
 > Ah, much simpler than that ;-) Was wondering if any of the code does
 > polling or wants frequent wakeups (as opposed to waiting for
 > events/signals) that would prevent them from getting swapped out...
 > 

nothing annoys me more (well, i guess that's probably an
exaggeration :-) than doing an strace to debug or investigate
some process and seeing it sitting there calling gettimeofday()
once a second.  so the only polling being done is in olpc-switchd,
where it checks the battery level and external power state once
every 15 seconds -- those pieces of information aren't available
as events.  (and of course it only reports the results to powerd
if they've changed.) ironically, battery and AC state _are_
available as wakeup events when we're asleep -- but not when
we're awake.

paul
=---------------------
 paul fox, pgf at laptop.org



More information about the Devel mailing list