Re: [PATCH 0/8] Suspend block api (version 6)

[Pavel Machek <pavel@ucw.cz>]

On Mon 2010-05-24 18:16:15, Arve Hj?nnev?g wrote:
> On Mon, May 24, 2010 at 11:57 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> >> I agree that the runtime scenario is a far more appealing one from an
> >> aesthetic standpoint, but so far we don't have a very compelling
> >> argument for dealing with the starting and stopping of userspace. The
> >> use-cases that Google have provided are valid and they have an
> >> implementation that addresses them, and while we're unable to provide an
> >> alternative that provides the same level of functionality I think we're
> >> in a poor position to prevent this from going in.
> >
> > Uhuh?
> >
> > "We have this ugly code here, but it works and we don't have better
> > one, so lets merge it"?
> >
> > I don't really like this line of reasoning. I would not want to judge
> > wakelocks here, but... "it works, merge it" should not be used as
> > argument.
> >
> > And btw I do have wakelock-less implementation of autosleep, that only
> > sleeped the machine when nothing was ready to run. It was called
> > "sleepy linux". Should I dig it out?
> >
> > Major difference was that it only sleeped the machine when it was
> > absolutely certain machine is idle and no timers are close to firing
> > -- needing elimination or at least markup of all short timers. It
> > erred on side of not sleeping the machine when it would break
> > something.
> >
> 
> How did you handle external events that occur right after you decided to sleep?

I decided to go to sleep with interrupts disabled... it was prototype
on x86, so it was rather tricky.

I'd expect external events after sleep decision to just wakeup machine
immediately, similar to entering deep CPU sleep mode...
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html