[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Peter Zijlstra on 27 May 2010 11:10 On Thu, 2010-05-27 at 16:05 +0100, Alan Cox wrote: > What is the problem here - your device driver for the display can block > tasks it doesn't want to use the display. Very well put again. I bet the next example is a proglet that does: while(1); without device interaction :-). -- 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 27 May 2010 11:30 On Thu, 27 May 2010 17:09:16 +0200 Peter Zijlstra <peterz(a)infradead.org> wrote: > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote: > > > > Opportunistic suspends are okay. > > > > The proposed userspace API is too Android-specific. > > I would argue opportunistic suspends are not ok, and therefore the > proposed API is utterly irrelevant. Assuming you are happy that opportunistically entering C6 and the like is ok via ACPI can you explain why you have a problem with opportunistic suspend and why it is different to a very deep sleep CPU state such as we have now (and which on many embedded platforms we deal with *is* sleeping external devices too) 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/
From: Peter Zijlstra on 27 May 2010 11:40 On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote: > On Thu, 27 May 2010 17:09:16 +0200 > Peter Zijlstra <peterz(a)infradead.org> wrote: > > > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote: > > > > > > Opportunistic suspends are okay. > > > > > > The proposed userspace API is too Android-specific. > > > > I would argue opportunistic suspends are not ok, and therefore the > > proposed API is utterly irrelevant. > > Assuming you are happy that opportunistically entering C6 and the like is > ok via ACPI can you explain why you have a problem with opportunistic > suspend and why it is different to a very deep sleep CPU state such as we > have now (and which on many embedded platforms we deal with *is* sleeping > external devices too) Agreed, but I understood the opportunistic suspend line from Alan Stern to mean the echo opportunistic > /sys/power/foo thing. If you view it as an extra deep idle state I have no problem with it (because its simply an idle state, nothing magic about those). -- 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 Stern on 27 May 2010 11:50 On Thu, 27 May 2010, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote: > > On Thu, 27 May 2010 17:09:16 +0200 > > Peter Zijlstra <peterz(a)infradead.org> wrote: > > > > > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote: > > > > > > > > Opportunistic suspends are okay. > > > > > > > > The proposed userspace API is too Android-specific. > > > > > > I would argue opportunistic suspends are not ok, and therefore the > > > proposed API is utterly irrelevant. > > > > Assuming you are happy that opportunistically entering C6 and the like is > > ok via ACPI can you explain why you have a problem with opportunistic > > suspend and why it is different to a very deep sleep CPU state such as we > > have now (and which on many embedded platforms we deal with *is* sleeping > > external devices too) > > Agreed, but I understood the opportunistic suspend line from Alan Stern > to mean the echo opportunistic > /sys/power/foo thing. Yes, that's what I meant. Why do you think it is any worse than "echo mem >/sys/power/state"? The only difference is that it will block until all in-kernel suspend blockers are disabled. Or do you also think that "echo mem >/sys/power/state" is evil and should be removed from the kernel as soon as possible? And to answer Thomas's question: The whole reason for having in-kernel suspend blockers is so that userspace can tell the system to suspend without losing wakeup events. Suppose a key is pressed just as a user program writes "mem" to /sys/power/state. The keyboard driver handles the keystroke and queues an input event. Then the system suspends and doesn't wake up until some other event occurs -- even though the keypress was an important one and it should have prevented the system from suspending. With in-kernel suspend blockers and opportunistic suspend, this scenario is prevented. That is their raison-d'etre. Alan Stern -- 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: Thomas Gleixner on 27 May 2010 12:10
On Thu, 27 May 2010, Alan Stern wrote: > On Thu, 27 May 2010, Peter Zijlstra wrote: > > > On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote: > > > On Thu, 27 May 2010 17:09:16 +0200 > > > Peter Zijlstra <peterz(a)infradead.org> wrote: > > > > > > > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote: > > > > > > > > > > Opportunistic suspends are okay. > > > > > > > > > > The proposed userspace API is too Android-specific. > > > > > > > > I would argue opportunistic suspends are not ok, and therefore the > > > > proposed API is utterly irrelevant. > > > > > > Assuming you are happy that opportunistically entering C6 and the like is > > > ok via ACPI can you explain why you have a problem with opportunistic > > > suspend and why it is different to a very deep sleep CPU state such as we > > > have now (and which on many embedded platforms we deal with *is* sleeping > > > external devices too) > > > > Agreed, but I understood the opportunistic suspend line from Alan Stern > > to mean the echo opportunistic > /sys/power/foo thing. > > Yes, that's what I meant. Why do you think it is any worse than "echo > mem >/sys/power/state"? The only difference is that it will block > until all in-kernel suspend blockers are disabled. > > Or do you also think that "echo mem >/sys/power/state" is evil and > should be removed from the kernel as soon as possible? > > And to answer Thomas's question: The whole reason for having in-kernel > suspend blockers is so that userspace can tell the system to suspend > without losing wakeup events. > > Suppose a key is pressed just as a user program writes "mem" to > /sys/power/state. The keyboard driver handles the keystroke and queues > an input event. Then the system suspends and doesn't wake up until > some other event occurs -- even though the keypress was an important > one and it should have prevented the system from suspending. > > With in-kernel suspend blockers and opportunistic suspend, this > scenario is prevented. That is their raison-d'etre. I tend to disagree. You are still looking at suspend as some extra esoteric mechanism. We should stop doing this and look at suspend (to RAM) as an additional deep idle state, which is well defined in terms of power savings and wakeup latency. That's what I think opportunistic suspend is all about. Now if you look at our current idle states in x86 the incoming keystroke is never lost. So when suspend does lose the wakeup event then we need to fix that, but why do we need suspend blockers for this ? Let's take your example: > The keyboard driver handles the keystroke and queues an input > event. Then the system goes into suspend .... Why do we go into suspend at all? If there is an event queued then something is woken up and got running, which is reason enough _not_ to enter suspend. If that's broken in the current implementation then we need to fix it, but not with a big hammer by adding another interface. We have that information already and obviously we do not use it, so lets figure out why before adding suspend blockers just because they paper over the underlying problem. Thanks, tglx -- 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/ |