Re: [PATCH 01/13] PM: Add wake lock api.

Pavel Machek
2009-03-04T14:13:23Z

On Wed 2009-03-04 15:00:01, Uli Luckas wrote:
> On Tuesday, 3. March 2009, Pavel Machek wrote:
> > Hi!
> >
> > > > > > And introduce nasty interface, and probably slower too since open()
> > > > > > is time-critical and ioctl() is not? Or do you have benchmarks?
> > > > >
> > > > > No, just specualting as open() needs to do a directory lookup. It
> > > > > also needs to do book keeping. I'd be surprised if open was faster
> > > > > then ioctl.
> > > >
> > > > Unless you measure how much slower it is...
> > >
> > > OK. Opening /dev/null 100000 times readonly takes 365 ms on my machine.
> > > Opening it once and then, 100000 times writing 1 byte takes 32 ms.
> > > Why exactly did you think I had to provide numbers???
> >
> > Arve said:
> > > >> I just checked my phone, and over a 24 hour awake time (370 hours
> > > >> uptime) period, it acquired about 5 million wakelocks (mostly for
> > > >> input events). If these were cache hits, and took as long as my
> > > >> benchmark did, that accounts for 20 seconds of overhead (0.023%
> > > >> of
> > > >> awake, 0.1% of not-idle (5.5h).
> >
> > Ok. 20seconds vs. 200 seconds seems interesting.
> >
> > OTOH... Android seems to do IPC for wakelock manipulation, and that's
> > way higher overhead than open() syscall, so perhaps it is not that
> > critical?
> >
> Is IPC (writing a byte through a pipe/socket) really more expensive than
> open/close?

Given that on current android it is "send a byte to another process
that does open/write/close"... yes that looks more expensive than
single open.

> here is network packets. You just don't want to open/close a fd for every
> network packet that you process. Neither for serial data, bluetooth
> packets, ...

You mix userland and kernel users.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html