[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: Matthew Garrett on 27 May 2010 13:50 On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote: > > we still need to be able to enter suspend while the system isn't idle. > > _WHY_!? Because if I'm running a kernel build in a tmpfs and I hit the sleep key, I need to go to sleep. Blocking processes on driver access isn't sufficient. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- 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 14:00 On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote: > If that's what you're aiming for then you don't need to block > applications on hardware access because they should all already have > idled themselves. Correct, a well behaved app would have. I thought we all agreed that well behaved apps weren't the problem? > > Note that it doesn't need to broadcast this, it could opt to reply with > > that message on the first drawing attempt after it goes away and block > > on the second. > > That's more interesting, but you're changing semantics quite heavily at > this point. So? -- 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: Matthew Garrett on 27 May 2010 14:00 On Thu, May 27, 2010 at 07:46:37PM +0200, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 18:41 +0100, Matthew Garrett wrote: > > On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote: > > > Then that's an application bug right there, isn't it? > > > > > > If should have listened to the window server telling its clients it was > > > going to go away. Drawing after you get that is your own damn fault ;-) > > > > How long do you wait for applications to respond that they've stopped > > drawing? What if the application is heavily in swap at the time? > > Since we're talking about a purely idle driven power saving, we wait > until the cpu is idle. If that's what you're aiming for then you don't need to block applications on hardware access because they should all already have idled themselves. > Note that it doesn't need to broadcast this, it could opt to reply with > that message on the first drawing attempt after it goes away and block > on the second. That's more interesting, but you're changing semantics quite heavily at this point. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- 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 14:00 > network packet arrives. The difference between these scenarios is large. Your application seems to change desired outcome every email. Sorry but you need to explicitly explain and define a policy in full that we can test ideas against. Otherwise this is useless. > > If you have wake-on-lan then the network stack might be smarter and > > choose to express itself as > > > > 'the constraint is C6 unless the input queue is empty in which > > case suspend is ok as I have WoL and my network routing is such > > that I can prove that interface will be used' > > This is still racy. Going back to this: > > int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0); > char foo; > struct sockaddr addr; > connect (input, &addr, sizeof(addr)) > while (1) { > if (read(input, &foo, 1) > 0) { > (do something) > } else { > * SUSPEND OCCURS HERE * Fine but then the packet will arrive and we will wake back up process the packet and wake the task. See suspend is just like a deep sleep. If we went to sleep there and the packet arrival doesn't rewake the box the driver was buggy. > reaches the end of its timeslice. At this point the application has not > had an opportunity to indicate in any way whether or not the packet has > altered its constraints in any way. What stops us from immediately > suspending again? If my app level constraint before the packet is 'don't suspend' then my constraint on receipt is 'don't suspend' so I won't suspend. If my constraint is then lowered and I suspend I will suspend *after* the lowering. If my constraint is tightened then the decision to tighten is run under the previous constraint. Which is fine, because if I have a case where I must tighten my constraint within the tight constraint time I've screwed up my app and need to fix it. In reality almost all your userspace is going to look like 'trusted app' or 'untrusted app' in droidthink and won't be transitioning in user space (but may well be adding/losing kernel constraints) This is good because it's another thing app authors don't have to care about. It's good because apps can be run trusted/untrusted without recompiling. 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: Matthew Garrett on 27 May 2010 14:00
On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote: > > > If that's what you're aiming for then you don't need to block > > applications on hardware access because they should all already have > > idled themselves. > > Correct, a well behaved app would have. I thought we all agreed that > well behaved apps weren't the problem? Ok. So the existing badly-behaved application ignores your request and then gets blocked. And now it no longer responds to wakeup events. So you penalise well-behaved applications without providing any benefits to badly-behaved ones. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- 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/ |