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

Uli Luckas
2009-03-05T17:42:05Z

On Wednesday, 4. March 2009, Pavel Machek wrote:
> 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
I don't know the details of sleepy linux so I'd appreciate if someone can
eluminate if the following scenarios could be handled efficiently with sleepy
linux:
1) You wake up through RTC, read the battery, update the color of your
fancy 'battery good' LED and go back to sleep imediately. The real work
takes milliseconds.
2) You send a request to the internet and go idle by selecting for an answer.
You probably don't want to go to sleep as you know, the answer will be
there shortly.

Uli

--

------- ROAD ...the handyPC Company - - - ) ) )

Uli Luckas
Head of Software Development

ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 62 | fax: +49 (30) 230069 - 69
url: www.road.de

Amtsgericht Charlottenburg: HRB 96688 B
Managing director: Hans-Peter Constien