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

Pavel Machek
2009-03-04T17:10:58Z

Hi!

> > > 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.

> No. I don't.
> The idea of wake locks was to hand locks over from a driver's interrupt all
> the way to userspace.
> This is done in an interlocked way to ensure that the device does not suspend
> from the time of interrupt until userspace has handled the event that caused
> the interrupt (e.g. A modem sending "RING" on the serial line).
> Basically, in a timerless wake lock implementation userspace has to take a
> wake lock every time select returns.

Well... in case it is really performance critical, we may want new
syscalls.

Actually, given how deep change of semantics this is, new syscalls may
be good idea.

Or better yet eliminate polling from userspace apps and just avoid
suspending whenever userspace is running (like sleepy patches do).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html