Suspend block api (version 6)
in [Kernel]
|
Prev: mm: fix race between shift_arg_pages and rmap_walk
Next: [PATCH -next] power: fix block_io.c printk warning
From: Pavel Machek on 26 May 2010 13:40 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(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Florian Mickler on 27 May 2010 04:10
On Thu, 27 May 2010 09:46:51 +0200 Linus WALLEIJ <linus.walleij(a)stericsson.com> wrote: > If yes then OK, it's not totally elegant but if that is > where we have to go, I can live with it. There will likely > be people who implement for only one or the other semantic > behaviour, but we have worse things to cope with already. Alan Cox suggested, that this kind of explicit requirement definition might be necessary for all drivers anyway in the long run. That way, the semantic differences between those two cases would vanish. Cheers, Flo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |