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.langh...@gmail.com> > From: p...@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.langh...@gmail.com> > From: p...@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: p...@laptop.org > From: Martin Langhoff <martin.langh...@gmail.com> > Subject: Re: Bxl testing report - April 16th > > On Fri, Apr 17, 2009 at 3:25 PM, <p...@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 de...@? > > > 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, p...@laptop.org
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
