[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: Rafael J. Wysocki on 27 May 2010 17:40 On Thursday 27 May 2010, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 13:32 -0400, Alan Stern wrote: > > > On some platforms (like those with ACPI), deeper power-savings are > > available by using forced suspend than by using idle. > > Sounds like something that's fixable, doesn't it? The fix would probably have to involve rewriting the ACPI spec. Rafael -- 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 17:40 On Thu, 27 May 2010, Alan Cox wrote: > > That's the point -- suspend does not evaluate the system state > > correctly because it doesn't have the necessary information. Suspend > > The power management layer knows if the machine is idle, it has insight > into when the next wakeups will occur. But not the kind of insight we need. See below. > > blockers are a way of providing it that information. They don't paper > > over the problem; they solve it. > > I'm still unconvinced (see Thomas examples as a starter) and even if they > did, the cure would be far worse than the disease. Perhaps. > The hardware world also shows how you handle suspend/resume event races > cleanly and in turn how we can handle right from user to hardware. > > If you are dealing with a well behaved UI app then its event loop will > just do > > if (message == UI_OFF) { > stop_background_stuff(); > event_mask &= stuff; > send_reply(NIGHT_NIGHT); > continue; > /* Back to poll() */ > } > > and power management does the rest. If an event wakes up the process > before we get to suspend in kernel we will wake it back up. Okay, and the kernel never suspends. We _are_ talking about a kind of forced suspend, right? > If the event > gets in after pm decides to idle via suspend then it'll bounce through > the kernel back to a kernel resume, No, it won't. That's the problem suspend blockers were meant to solve. The event winds up sitting in a kernel queue, the PM core doesn't know about it (that's what I meant above -- the PM core doesn't know as much as you seem to think it does), and the suspend takes place regardless. > or potentially through a full > hardware/software suspend/resume bounce. It would be okay if that happened. But once the event gets into the kernel and the hardware IRQ source has turned off, there's nothing to cause the resume. > You have one person who needs to > track the sequence - that's however is the guy sending UI_ON/UI_OFF > information and making the screen light up. > > If you are dealing with a badly behaved app then you can't win because it > may not have the magic 'suspend blockers' or will do it wrong. Agreed. Badly behaved apps must not be allowed to block suspends. As far as I'm concerned, we can ignore them. 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: Alan Stern on 27 May 2010 17:50 On Thu, 27 May 2010, Thomas Gleixner wrote: > > The two of you are talking at cross purposes. Thomas is referring to > > idle-based suspend and Matthew is talking about forced suspend. > > Yes, and forced suspend to disk is the same as force suspend to disk, > which has both nothing to do with sensible resource management. If I understand correctly, you are saying that all the untrusted applications should run with QoS(NONE). Then they could do whatever they wanted without causing any interference. And with idle-based power management (rather than forced suspend), there would be no issue with wakeup events getting unduly delayed. Unless one of those events was meant for an untrusted application. Is that the source of the difficulty? 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: Alan Cox on 27 May 2010 17:50 On Thu, 27 May 2010 23:36:26 +0200 "Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: > On Thursday 27 May 2010, Peter Zijlstra wrote: > > On Thu, 2010-05-27 at 13:32 -0400, Alan Stern wrote: > > > > > On some platforms (like those with ACPI), deeper power-savings are > > > available by using forced suspend than by using idle. > > > > Sounds like something that's fixable, doesn't it? > > The fix would probably have to involve rewriting the ACPI spec. We are on about the fourth version of ACPI already. ACPI evolves and improves and extends. It's not an impossibility to sort that out if everyone in the x86 OS world starts thinking 'How come their ARM platform can do this' We are also on at least the second suspend/resume model in Linux. The first was 'isn't this APM stuff neat', the second is heavily oriented around ACPI ideas. And we already have SoC people moving into the third model and making it work on non-x6 ('suspend is not special'). I've not poked at the current desktop stuff enough to see if the gnome-power-manager and friends handle pushing the suspend button with dbus notifiers to apps. I guess it does. 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: Thomas Gleixner on 27 May 2010 17:50
On Thu, 27 May 2010, Rafael J. Wysocki wrote: > On Thursday 27 May 2010, Thomas Gleixner wrote: > > On Thu, 27 May 2010, Alan Stern wrote: > > > > > On Thu, 27 May 2010, Felipe Balbi wrote: > > > > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: > > > > >If people don't mind, here is a greatly simplified summary of the > > > > >comments and objections I have seen so far on this thread: > > > > > > > > > > The in-kernel suspend blocker implementation is okay, even > > > > > beneficial. > > > > > > > > I disagree here. I believe expressing that as QoS is much better. Let > > > > the kernel decide which power state is better as long as I can say I > > > > need 100us IRQ latency or 100ms wakeup latency. > > > > > > Does this mean you believe "echo mem >/sys/power/state" is bad and > > > should be removed? Or "echo disk >/sys/power/state"? They pay no > > > > mem should be replaced by an idle suspend to ram mechanism > > Well, what about when I want the machine to suspend _regardless_ of whether > or not it's idle at the moment? That actually happens quite often to me. :-) Fair enough. Let's agree on a non ambigous terminology then: forced: suspend which you enforce via user interaction, which also implies that you risk losing wakeups depending on the hardware properties opportunistic: suspend driven from the idle context, which guarantees to not lose wakeups. Provided only when the hardware does provide the necessary capabilities. 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/ |