[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 14:30 On Thu, May 27, 2010 at 07:59:02PM +0200, Thomas Gleixner wrote: > On Thu, 27 May 2010, Matthew Garrett wrote: > > ACPI provides no guarantees about what level of hardware functionality > > remains during S3. You don't have any useful ability to determine which > > events will generate wakeups. And from a purely practical point of view, > > since the latency is in the range of seconds, you'll never have a low > > enough wakeup rate to hit it. > > Right, it does not as of today. So we cannot use that on x86 > hardware. Fine. That does not prevent us to implement it for > architectures which can do it. And if x86 comes to the point where it > can handle it as well we're going to use it. Where is the problem ? If > x86 cannot guarantee the wakeup sources it's not going to be used for > such devices. The kernel just does not provide the service for it, so > what ? We were talking about PCs. Suspend-as-c-state is already implemented for OMAP. > So the only thing you are imposing to app writers is to use an > interface which solves nothing and does not save you any power at > all. It's already been demonstrated that the Android approach saves power. > Runnable tasks and QoS guarantees are the indicators whether you can > go to opportunistic suspend or not. Everything else is just window > dressing. As I keep saying, this is all much less interesting if you don't care about handling suboptimal applications. If you do care about them then the Android approach works. Nobody has demonstrated a scheduler-based one that does. -- 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: Matthew Garrett on 27 May 2010 14:40 On Thu, May 27, 2010 at 08:22:08PM +0200, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 19:17 +0100, Matthew Garrett wrote: > > > It's blocked on the screen being turned off. It's supposed to be reading > > a network packet. How does it ever get to reading the network packet? > > Its blocked because its a buggy app, who cares about misbehaviour in a > buggy app? So why bother blocking? Just kill the app and tell the user. If you want to support suboptimal apps then blocking isn't sufficient. If you don't want to then blocking isn't necessary. -- 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: Zygo Blaxell on 27 May 2010 14:40 On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote: > So you need > > Userspace -> QoS guarantee expression, implied resource > expression via device use. *NO* knowledge of > device or platform in the application I have a pile of use cases where I want to turn off "implied resource expression via device use." There are two orthogonal variables to consider: 1. I'm drawing cows on the screen (or asking another process to do so on my behalf). 2. I care whether anyone can actually see the cows, and I'm willing (or not) to burn power to make them visible. Quite often, I'm drawing cows but I don't care about cow visibility, so I would tell PM to turn the display off when the PM framework is looking for ways to conserve power; however, if the animated cow is part of an alarm clock application, then I want the display on, powering it up if was previously turned off. A real-world example of this is a backup process on a file server. I'd like to tell the kernel that the backup process's CPU usage and disk I/O is *not* implied resource expression, and if there's no other processes using the CPU or disks, the kernel can just power down the drives or idle the CPU on a whim. The backup process can hang until some other process comes along to wake the drives and CPU up again, and then the backups will run during the idle time while the drive is waiting for new requests from other processes. Obviously if the backup process is trying to write dirty pages to a powered-down drive there will be problems (memory starvation and lost data come to mind), so I'd make sure I don't do that. I'd also like to change my mind about these sorts of things on the fly, without requiring hooks in the backup process itself. I'm thinking of a syscall with PID, FD, mode bits (read/write? iowait/runnable?), and policy (whether usage implies expression). I can express mostly the same things if "policy" was "maximum latency," but not all. Consider how you'd have to specify latencies to get hard disks that spin down when idle, spin up immediately if read requests are issued, but wait several minutes to spin up if write requests are issued. I can't specify that with a single latency value since it would result in either unacceptably large latencies in some cases, or the disks would never spin down. I'd need a matrix with drive power states as rows and read/write operations as columns, either per process or per file descriptor. Also something in user-space needs to know about the approximate value for hard disk spin-up times in order to set their PM QoS constraints high enough to be useful but also low enough to be useful. Well, maybe the last problem can be resolved by specifying QoS constraints in bands. You'd have a QOS_OTHER band that applies to processes that haven't specified a constraint, and a QOS_EXPLICIT band that applies to those that have, and you'd be able to change all the QOS_OTHER processes at once. -- 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: Kevin Hilman on 27 May 2010 14:50 Matthew Garrett <mjg59(a)srcf.ucam.org> writes: > On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote: > >> I'd prefer we avoided mixing them up. Everyone seems fairly happy with >> the current operator ordered suspend behaviour I believe ? > > No. The current mechanism can lose wakeup events. And the proposed solution (suspend blockers) does nothing to solve the loss of wakeup events during forced suspend. Kevin -- 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:50
> Yes, there's no problem so far. The question is how you guarantee that > the application has had the opportunity to handle the packet. Because the application has said that it wants QoS guarantees. It wants to know that if the events it can receive occur it will wake up within the timescale. So it receives the event. It's now running, not idle so we won't suspend it. At some point in time it will become idle again _or_ the CPU limit will get it. If the app is not trusted then we might suspend it before it handles the packet. That is fine, it's not trusted and we will do that when we decide its in the system interest to suspend it anyway. You still don't lose the event because on resume the task will do its processing. > The application is a network monitoring app that renders server state > via animated bouncing cows. The desired behaviour is that the > application will cease to be scheduled if the session becomes idle > (where idle is defined as the system having received no user input for > 30 seconds) but that push notifications from the server still be > received in order to allow the application to present the user with > critical alerts. This is a bit confusing - does the screen come back on for such events, what constraints is the server operating under ? How does your code look - it's hard to imagine the examples you've given as being workable given they would block on network packet wait when a critical event occurs. Are you using poll or threads or what ? > Under Android: > > User puts down phone. 30 seconds later the screen turns off and releases > the last user-level suspend block. The phone enters suspend and the > application is suspended. A network packet is received, causing the > network driver to take a suspend block. The application finishes the > frame it was drawing, takes its own suspend block and reads the network > packet. In doing so the network driver releases its suspend block, but > since userspace is holding one the phone stays awake. The application > then handles the event as necessary, releases its suspend block and the > phone goes to sleep again. > > I don't see how this behaviour can be emulated in your model. User puts down phone. 30 seconds later the X server decides to turn the screen off and closes the device. This probalby releases the constraint held via the display driver not to suspend. Any further draw requests will block. System looks at the other tasks and sees they are idle and can sink to a low power state. Cows is either blocked on a packet receive or could even be blocked on writing to the display (or both if its a realistic example and using poll) Everyone is idle, we can sleep The kernel looks at the constraints it has - must not sink to a state below which network receive of packets fails - must not sink below a state where whatever is needed for the critical alert code etc to do its stuff - must not sink to a state which takes more than [constraint] seconds to get back out of It picks 'opportunistic suspend' It goes to sleep A packet arrives It wakes the hardware We are busy, we do not wish to suspend It processes the packet It wakes the user app It starts processing the packet [We are busy, we do not wish to suspend] Presumably your display server listens to waking back up and decides to re-activate the screen (your example is unclear and implies it carries on processing the extra frame in the dark which seems a bit silly ? I still don't see a problem. I think your problem arises because you start from the basis that forcing suspend is special. As Thomas has said there are working implementations where suspend is an idle mode. The moment you discard that specific notion everything works, as it does today on other embedded platforms. Now what do you do if the app is burning too much processor time. That's a QoS question too. We've got cpu limits, we've got SIGXCPU, we don't have "cpu per second" type limits but that isn't hard to do either. Stop transitioning Run->Forced Suspend. If you've got stuff stuck running then deal with it by constraining it to go idle or by blowing it out of the water. PM will then do the rest. -- 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/ |