Suspend block api (version 8)
in [Kernel]
|
From: Arve Hjønnevåg on 26 May 2010 06:50 2010/5/26 Peter Zijlstra <peterz(a)infradead.org>: > On Wed, 2010-05-26 at 03:25 -0700, Arve Hj�nnev�g wrote: > >> and on systems where the >> same power state can be used from idle and suspend, we use suspend so >> we can stay in the low power state for minutes to hours instead of >> milliseconds to seconds. > > So don't you think working on making it possible for systems to be idle > _that_ long would improve things for everybody? as opposed to this > auto-suspend which only improves matters for those that (can) use it? I'm not preventing anyone from working on improving this. Currently both the kernel and our user-space code polls way too much. I don't think it is reasonable to demand that no one should run any user-space code with periodic timers when we have not even fixed the kernel to not do this. -- Arve Hj�nnev�g -- 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: Arve Hjønnevåg on 26 May 2010 07:00 2010/5/26 Peter Zijlstra <peterz(a)infradead.org>: > On Wed, 2010-05-26 at 03:40 -0700, Arve Hj�nnev�g wrote: >> 2010/5/26 Peter Zijlstra <peterz(a)infradead.org>: >> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hj�nnev�g wrote: >> > >> >> and on systems where the >> >> same power state can be used from idle and suspend, we use suspend so >> >> we can stay in the low power state for minutes to hours instead of >> >> milliseconds to seconds. >> > >> > So don't you think working on making it possible for systems to be idle >> > _that_ long would improve things for everybody? as opposed to this >> > auto-suspend which only improves matters for those that (can) use it? >> >> I'm not preventing anyone from working on improving this. Currently >> both the kernel and our user-space code polls way too much. I don't >> think it is reasonable to demand that no one should run any user-space >> code with periodic timers when we have not even fixed the kernel to >> not do this. > > All I'm saying is that merging a stop-gap measure will decrease the > urgency and thus the time spend fixing the actual issues while adding > the burden of maintaining this stop-gap measure. > Fixing the actually issue means fixing all user-space code, and replacing most x86 hardware. I don't think keeping this feature out of the kernel will significantly accelerate this. -- Arve Hj�nnev�g -- 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: Peter Zijlstra on 26 May 2010 07:20 On Wed, 2010-05-26 at 03:53 -0700, Arve Hjønnevåg wrote: > 2010/5/26 Peter Zijlstra <peterz(a)infradead.org>: > > On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote: > >> 2010/5/26 Peter Zijlstra <peterz(a)infradead.org>: > >> > On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote: > >> > > >> >> and on systems where the > >> >> same power state can be used from idle and suspend, we use suspend so > >> >> we can stay in the low power state for minutes to hours instead of > >> >> milliseconds to seconds. > >> > > >> > So don't you think working on making it possible for systems to be idle > >> > _that_ long would improve things for everybody? as opposed to this > >> > auto-suspend which only improves matters for those that (can) use it? > >> > >> I'm not preventing anyone from working on improving this. Currently > >> both the kernel and our user-space code polls way too much. I don't > >> think it is reasonable to demand that no one should run any user-space > >> code with periodic timers when we have not even fixed the kernel to > >> not do this. > > > > All I'm saying is that merging a stop-gap measure will decrease the > > urgency and thus the time spend fixing the actual issues while adding > > the burden of maintaining this stop-gap measure. > > > > Fixing the actually issue means fixing all user-space code, and > replacing most x86 hardware. I don't think keeping this feature out of > the kernel will significantly accelerate this. I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere near fast enough for this to be usable. My laptop still takes several seconds to suspend (Lenovo T500), and resume (aside from some userspace bustage) takes the same amount of time. That is quick enough for manual suspend, but I'd hate it to try and auto-suspend. Getting longer idle periods however is something that everybody benefits from. On x86 we're nowhere close to hitting the max idle time of the platform, you get _tons_ of wakeups on current 'desktop' software. But x86 being a PITA shouldn't stop people from working on this, there's plenty other architectures out there, I remember fixing a NO_HZ bug with davem on sparc64 because his niagra had cores idling for very long times indeed. So yes, I do think merging this will delay the effort in fixing userspace, simply because all the mobile/embedded folks don't care about it anymore. -- 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 26 May 2010 07:40 On Wed, 26 May 2010 11:54:37 +0200 Peter Zijlstra <peterz(a)infradead.org> wrote: > On Wed, 2010-05-26 at 11:40 +0200, Florian Mickler wrote: > > _IF_ you want to suspend aggressively, I don't see another > > way. > > > > The thing is, this is a paradigm change. Suspend is not anymore > > controlled by userspace. In order to let userspace control/work with > > this scheme, it needs to know when a suspend will be successfull or > > poll: > > > > 1. kernel sees suspend may be possible on his side of things > > > > 2. kernel sends a message to userspace that i could be possibly > > possible to suspend, but it may well be that by the time > > userspace suspends it is not possible anymore > > > > 3. userspace decides to suspend. > > > > <- system suspends... or not ..-> > > > > 4. userspace retries ... retries ... retries ... > > > > And then you have the whole can of worms and races. > > I don't see any races, nor retry loops. What about the worms? :) I referred to retrying steps 1 through 3 as being the loop. > > There is always the race of an event arriving whilst in the process of > suspending, that is not solved by either the kernel nor user part of > suspend-blockers. The only thing is not to loose the event. > > You simply have to deal with that, the suspend gets canceled, you do > deal with the event, and suspend again. How does making that 'retry' as > you call it happen from a kernel thread or from a userspace thread any > difference? > You have a point there. But what follows? You either need to let userspace know that the kernel is now able to suspend or you let the kernel know that userspace is now able to suspend. Else you can not make a well informed suspend-decision and have to guess and retry. Why not look at blocking and unblocking as these events you want to have? Without wiggle room and retrying. And not having to route through userspace simplifies the auto-suspend scheme further. 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/
From: Alan Cox on 26 May 2010 08:30
> I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere > near fast enough for this to be usable. Yet... > My laptop still takes several seconds to suspend (Lenovo T500), and > resume (aside from some userspace bustage) takes the same amount of > time. That is quick enough for manual suspend, but I'd hate it to try > and auto-suspend. This is an area where machines are improving and where the ability to do stuff like autosuspend, the technology like the OLPC screen and so on create an incentive for the BIOS and platform people to improve their bits of it. > So yes, I do think merging this will delay the effort in fixing > userspace, simply because all the mobile/embedded folks don't care about > it anymore. The mobile space probably doesn't care too much about many of the large bloated desktop apps anyway and traditional embedded generally has a very small fixed application set where the optimise both halves of the system together. Alan -- 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/ |