HTC Dream drivers was Re: [linux-pm] suspend blockers Android integration
Hi! So for people who really care about running a mainline kernel on their android device doing that part first on a generic ARM board in qemu might be much better first step work. On the other hand I've heard that various hardware vendors or parties closed to them are rather annoyed by their drivers beeing stuck in the android tree - but that can be easily solved by getting removing the suspend blockers (at least temporarily), cleaning up a few bits here and there and getting them in. This continues to baffle me. If we (Google) are such a headache, why not just route around us. The drivers we've written are GPLv2, the Well, we did route around you, and that's why the HTC Dream drivers are in staging. Unfortunately... source is out there for anyone who wants it, etc. The drivers other people have written we have no control over at all. From my point of view it'd be an annoyance if somebody took the code we wrote, modified it heavily, and pushed it upstream, but fundamentally I can't stop that from happening other than by pushing it upstream myself, first. ...you were calling bloody murder when we tried to name them right way -- thats board_dream, not board_trout -- and AFAIK you still did not switch to actually using those drivers so that diffs would grow smaller... And no, it is not 'just arm architecture #1536'; due to strange baseband/cpu split in msm drivers end up quite bigcomplex... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Fri, 11 Jun 2010, Arve Hjønnevåg wrote: Wait a second. Maybe I have misunderstood how timeouts are supposed to work with wakelocks. I thought the idea was that the wakelock would be released when the timeout expires or the event queue is emptied, That is one way to use it, and I did this so code that opened an input device without reading from it would not prevent suspend forever. In the last patchset I posted, I instead used an ioctl to enable the suspend blocker. whichever comes first. Now it sounds like you're saying that the wakelock doesn't get released until the timeout expires, even if userspace finishes processing all pending events before then. For incoming network traffic we use a wakelock with a timeout to prevent suspend long enough for the data to make it to user-space since we have not added wakelocks to the network stack. We did this to avoid changing to the network stack, tty layer, etc. I see. These are examples where wakelocks are _not_ released by any userspace action, so they don't seem to fit well into my all-userspace scheme. At least, not in their current form. On the other hand, if the network/tty wakeup events eventually cause data to become available on a socket or device file, then they wouldn't need any special treatment in my scheme. The socket/file descriptors could be handled the same as any others. (Although you might need to change some apps, to make them follow the usual pattern of poll, activate suspend blocker, read, process, release suspend blocker.) In other words, the fact that everything has been moved into userspace means that you wouldn't have to worry about the missing wakelocks in the network stack or tty layer, and consequently wouldn't have to worry about using timed wakelocks there. Sure. But specifically, which drivers on Android generate wakeup events? And which of them don't fully handle their events in their interrupt handlers? Keypad, network, charger, rtc, but I'm sure I forgot some. Maybe another way to put this is: Where in the kernel do you intend to add suspend blockers? In addition to the drivers that enable the wakeup events, we have added suspend blockers to the input event code and power supply framework. The tty layer and network stack would also need suspend blockers to avoid using timeouts. I see. The keypad, charger (power supply), and rtc drivers sound pretty platform-specific. Probably nobody would complain too strongly about adding suspend blockers there. The input, network, and tty layers are more general, though. That's where you're most likely to encounter resistance. People have been complaining about suspend blockers being added all throughout the kernel. It might help if you pointed out that it's just in these three layers (and maybe at only a few specific points within each layer). Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Fri, Jun 11, 2010 at 04:48:15PM -0400, Alan Stern wrote: On Fri, 11 Jun 2010, Mark Brown wrote: The clock framework is implemented independantly for each CPU. That's not an impediment, since drivers' requirements regarding which clocks remain running in which power states are necessarily platform-dependent also. It does mean that you can't make any general statements about what the clock framework does and doesn't do which is what the person I was replying to (the quoting you did as you cut'n'pasted replies to multiple messages seems more than a little confused, sorry) seemed to want. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote: Do we at least have a clean way that a driver can reject a system suspend? I've lost track of many issues, but maybe this could be phrased as a QOS constraint: the current config of driver X needs clock Y active to enter the target system suspend state, driver's suspend() method reports as much. Then the entry to that system state gets blocked if the clock isn't enabled. So in QoS modifications to android patches, the answer is yes ... except that the current android patch set didn't actually have this type of wakelock in it. Android wants an idleness suspend block (or pm qos constraint) that a driver can set to prevent the system idleness power govenor from dropping into a power state too low for the driver, so in USB terms this would prevent the states that shut down the clock. For android, it prevented shutdown of an internal i2c bus. The one thing that does look difficult is that these power constraints are device (and sometimes SoC) specific. Expressing them in a generic way for the cpu govenors to make sense of might be hard. (That QOS constraint should be removed when that driver no longer needs to issue wakeups; that's not quite the same as removed by driver.resume(). The USB one needs user input, doesn't it, since user hot plug might (or might not) be one of the wakeup sources. James -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Thu, 10 Jun 2010, Arve Hjønnevåg wrote: You've lost me. If the power manager is sitting inside a select/poll, how can it miss the event (given that the event will make data available to be read on one of the descriptors being polled)? It cannot sit inside of select/poll all the time. Or put it another way: With wakelocks, if the app doesn't use a suspend blocker then once it reads the event data and the timed wakelock is deactivated, there is nothing to prevent the system from immediately going into opportunistic suspend. My scheme can fail in the same way. Is that what you meant? No, if an app reads from a file descriptor and block suspend when the read call returns, then suspend is blocked while processing the data. If the driver uses a wakelock with a timeout this will fail if the thread does not get to the suspend block call before the timeout expires, but unrelated events that don't prevent the app from running will not cause any problems. Wait a second. Maybe I have misunderstood how timeouts are supposed to work with wakelocks. I thought the idea was that the wakelock would be released when the timeout expires or the event queue is emptied, whichever comes first. Now it sounds like you're saying that the wakelock doesn't get released until the timeout expires, even if userspace finishes processing all pending events before then. In your scheme the user-space power manager may miss events on this file descriptor since select/poll will not see an event if the app read that event right before the power manager called select/poll. If the wakelock is supposed to remain active until the timeout expires then you are right. On the other hand, this seems like a rather strange and suspicious way of handling wakelocks. Why would you want to do it that way? There's one question that I don't remember ever seeing answered. To which kernel drivers do you intend to add suspend blockers? All drivers that generate wakeup events need to either use suspend blockers directly or call into something else that does. For instance, with the patch to block suspend while input events are queued to user-space, an input driver that fully handles its events in its interrupt handler does not need any additional suspend blockers, but if the driver needs a work function or a timer to run before it reports the event it needs to block suspend until it has reported the event. Sure. But specifically, which drivers on Android generate wakeup events? And which of them don't fully handle their events in their interrupt handlers? Maybe another way to put this is: Where in the kernel do you intend to add suspend blockers? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Thu, 10 Jun 2010, David Brownell wrote: This is a bit off the topic of Android flamage, but I thought it would be worth highlighting an example where the current frameworks may still have a deficiency... one that likewise relates to needing to block entry ot a system suspend state, but in this case user-space isn't very involved (just drivers coping with hardware). The example I wanted to re-post (I've done so in the past) is one where drivers ouldn't really do the right thing, since driver.suspend() wasn't quite powerful enough as a programming interface. The example works with USB on many ARM SoCs, and similar non-USB examples aren't rare. - Want to enter a system suspend state, with some USB wakeup sources. USB peripheral waken up by the host, or vice versa. NOTE ASSUMPTION: there are multiple suspend states supported by the hardware, significantly different in hardware configuration Linux should be able to use more than one such state... (if only because their power savings differ.) This can mean driver-specific knowledge about those various states. - The wakeup requires a particular clock to be active, so the USB controller can detect that the wakeup should trigger, then issue the right signals triggering the non-USB parts of the system. Problem: how does the device driver suspend() method block entry to a suspend state when it can't ensure that clock is going to be active. Magic return code? At the moment, drivers aren't told what suspend state the system is going into. They know the difference between suspend and hibernate, but the PM core doesn't tell drivers whether it's going into standby vs. suspend. (Strictly speaking, those terms apply mostly to ACPI systems and not so much elsewhere. What I'm talking about is the /sys/power/state interface, where the user can write either standby or mem. Drivers aren't told which was written.) There are other issues here too. (Is the target system suspend state one of the ones which doesn't allow that clock to be active? SoC-specific calls might suffice for this issue. I imagine platforms have to answer all such questions when they decide exactly how they will implement standby and mem. A number of years ago, this problem was insoluble with the then-current Linux PM and clock frameworks. I've been away from this issue for quite a while now, but don't recall seeing its sub-problems get solved ... If they're now solved, I'll be glad. (I know Kevin's recent OMAP stuff addresses similar issues, but It's OMAP-specific...) After all these thousands and thousands of emails... I'm not sure how much forward motion has happened. I'm not aware of any progress. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Fri, 11 Jun 2010, James Bottomley wrote: On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote: Do we at least have a clean way that a driver can reject a system suspend? I've lost track of many issues, but maybe this could be phrased as a QOS constraint: the current config of driver X needs clock Y active to enter the target system suspend state, driver's suspend() method reports as much. Then the entry to that system state gets blocked if the clock isn't enabled. So in QoS modifications to android patches, the answer is yes ... except that the current android patch set didn't actually have this type of wakelock in it. Android wants an idleness suspend block (or pm qos constraint) that a driver can set to prevent the system idleness power govenor from dropping into a power state too low for the driver, so in USB terms this would prevent the states that shut down the clock. For android, it prevented shutdown of an internal i2c bus. The one thing that does look difficult is that these power constraints are device (and sometimes SoC) specific. Expressing them in a generic way for the cpu govenors to make sense of might be hard. Doesn't the clock framework already handle this sort of thing? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote: On Fri, 11 Jun 2010, James Bottomley wrote: The one thing that does look difficult is that these power constraints are device (and sometimes SoC) specific. Expressing them in a generic way for the cpu govenors to make sense of might be hard. Doesn't the clock framework already handle this sort of thing? The clock framework is implemented independantly for each CPU. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Fri, 2010-06-11 at 10:46 -0400, Alan Stern wrote: On Fri, 11 Jun 2010, James Bottomley wrote: On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote: Do we at least have a clean way that a driver can reject a system suspend? I've lost track of many issues, but maybe this could be phrased as a QOS constraint: the current config of driver X needs clock Y active to enter the target system suspend state, driver's suspend() method reports as much. Then the entry to that system state gets blocked if the clock isn't enabled. So in QoS modifications to android patches, the answer is yes ... except that the current android patch set didn't actually have this type of wakelock in it. Android wants an idleness suspend block (or pm qos constraint) that a driver can set to prevent the system idleness power govenor from dropping into a power state too low for the driver, so in USB terms this would prevent the states that shut down the clock. For android, it prevented shutdown of an internal i2c bus. The one thing that does look difficult is that these power constraints are device (and sometimes SoC) specific. Expressing them in a generic way for the cpu govenors to make sense of might be hard. Doesn't the clock framework already handle this sort of thing? Well, there are two elements to this sort of thing: 1. Allow a driver to request that a given clock not be turned off. 2. Make the cpuidle governors aware of a pending don't turn off X clock source so they can keep the system in a state where the clock doesn't get powered down. As far as I can tell from the code, neither currently exists at the moment. James -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Fri, 11 Jun 2010, Mark Brown wrote: On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote: On Fri, 11 Jun 2010, James Bottomley wrote: The one thing that does look difficult is that these power constraints are device (and sometimes SoC) specific. Expressing them in a generic way for the cpu govenors to make sense of might be hard. Doesn't the clock framework already handle this sort of thing? The clock framework is implemented independantly for each CPU. That's not an impediment, since drivers' requirements regarding which clocks remain running in which power states are necessarily platform-dependent also. On Fri, 11 Jun 2010, James Bottomley wrote: Well, there are two elements to this sort of thing: 1. Allow a driver to request that a given clock not be turned off. 2. Make the cpuidle governors aware of a pending don't turn off X clock source so they can keep the system in a state where the clock doesn't get powered down. As far as I can tell from the code, neither currently exists at the moment. Well then, can (or should) the clock framework interact with the pm-qos subsystem so that drivers don't have to worry about it? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Fri, 2010-06-11 at 16:48 -0400, Alan Stern wrote: On Fri, 11 Jun 2010, Mark Brown wrote: On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote: On Fri, 11 Jun 2010, James Bottomley wrote: The one thing that does look difficult is that these power constraints are device (and sometimes SoC) specific. Expressing them in a generic way for the cpu govenors to make sense of might be hard. Doesn't the clock framework already handle this sort of thing? The clock framework is implemented independantly for each CPU. That's not an impediment, since drivers' requirements regarding which clocks remain running in which power states are necessarily platform-dependent also. On Fri, 11 Jun 2010, James Bottomley wrote: Well, there are two elements to this sort of thing: 1. Allow a driver to request that a given clock not be turned off. 2. Make the cpuidle governors aware of a pending don't turn off X clock source so they can keep the system in a state where the clock doesn't get powered down. As far as I can tell from the code, neither currently exists at the moment. Well then, can (or should) the clock framework interact with the pm-qos subsystem so that drivers don't have to worry about it? So the implementation of this seems to be a bit complex: We could have clockevents_register() do a per clock pm_qos variable but then the cpuidle governors need to know which to listen for so they don't transition to a state too low for them to be active if pm_qos says keep them running. Even if that gets sorted out, how would USB know which platform specific clock source is driving the wakeup events on its bus? How complex can SoC clocksources be? If it's just a simple binary do/don't potentially stop all clocks, I think it's easy. If SoC's have a hierarchical shutdown sequence, and they really need this to save power, then expressing that generically becomes rather problematic. James -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/11 Alan Stern st...@rowland.harvard.edu: On Thu, 10 Jun 2010, Arve Hjønnevåg wrote: You've lost me. If the power manager is sitting inside a select/poll, how can it miss the event (given that the event will make data available to be read on one of the descriptors being polled)? It cannot sit inside of select/poll all the time. Or put it another way: With wakelocks, if the app doesn't use a suspend blocker then once it reads the event data and the timed wakelock is deactivated, there is nothing to prevent the system from immediately going into opportunistic suspend. My scheme can fail in the same way. Is that what you meant? No, if an app reads from a file descriptor and block suspend when the read call returns, then suspend is blocked while processing the data. If the driver uses a wakelock with a timeout this will fail if the thread does not get to the suspend block call before the timeout expires, but unrelated events that don't prevent the app from running will not cause any problems. Wait a second. Maybe I have misunderstood how timeouts are supposed to work with wakelocks. I thought the idea was that the wakelock would be released when the timeout expires or the event queue is emptied, That is one way to use it, and I did this so code that opened an input device without reading from it would not prevent suspend forever. In the last patchset I posted, I instead used an ioctl to enable the suspend blocker. whichever comes first. Now it sounds like you're saying that the wakelock doesn't get released until the timeout expires, even if userspace finishes processing all pending events before then. For incoming network traffic we use a wakelock with a timeout to prevent suspend long enough for the data to make it to user-space since we have not added wakelocks to the network stack. In your scheme the user-space power manager may miss events on this file descriptor since select/poll will not see an event if the app read that event right before the power manager called select/poll. If the wakelock is supposed to remain active until the timeout expires then you are right. On the other hand, this seems like a rather strange and suspicious way of handling wakelocks. Why would you want to do it that way? We did this to avoid changing to the network stack, tty layer, etc. There's one question that I don't remember ever seeing answered. To which kernel drivers do you intend to add suspend blockers? All drivers that generate wakeup events need to either use suspend blockers directly or call into something else that does. For instance, with the patch to block suspend while input events are queued to user-space, an input driver that fully handles its events in its interrupt handler does not need any additional suspend blockers, but if the driver needs a work function or a timer to run before it reports the event it needs to block suspend until it has reported the event. Sure. But specifically, which drivers on Android generate wakeup events? And which of them don't fully handle their events in their interrupt handlers? Keypad, network, charger, rtc, but I'm sure I forgot some. Maybe another way to put this is: Where in the kernel do you intend to add suspend blockers? In addition to the drivers that enable the wakeup events, we have added suspend blockers to the input event code and power supply framework. The tty layer and network stack would also need suspend blockers to avoid using timeouts. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
--- On Fri, 6/11/10, James Bottomley james.bottom...@suse.de wrote: Do we at least have a clean way that a driver can reject a system suspend? I've lost track of many issues, but maybe this could be phrased as a QOS constraint: the current config of driver X needs clock Y active to enter the target system suspend state, driver's suspend() method reports as much. Then the entry to that system state gets blocked if the clock isn't enabled. So in QoS modifications to android patches, the answer is yes ... except that the current android patch set didn't actually have this type of wakelock in it. Except, we're not talking wakelock ... :) So ... no, these cases still have no solution. (I think that's at least five years now.) The one thing that does look difficult is that these power constraints are device (and sometimes SoC) specific. Exactly why they make good examples for turning up framework limitations... like having overlooked constraints coming from various SoC peripherals. Expressing them in a generic way for the cpu govenors to make sense of might be hard. Requiring CPU governors to be involved in such stuff feels a bit off-course to me. At least, if the involvement is very deep. The constraints are from the integrated peripherals, not (usually) from the CPU There are plent of places to hang SoC or device specific data, once there's awareness that without such data, (which PCs hide behind ACPI bytecode) the PM framework is missing out on support for some desirable low power modes. (That QOS constraint should be removed when that driver no longer needs to issue wakeups; that's not quite the same as removed by driver.resume(). The USB one needs user input, doesn't it, I don't quite see that. The drivers get called in enough places, and they'll know if the system is going to be in a suspend state where they need to be partially aactive (with various QOS constraints, or they can't work. since user hotplug might (or might not) be one of the wakeup sources. If it wakes via hotplug, then the driver must already Do The Right Thing; what input would be needed (Beyond changing the cable config)? James -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Thursday, June 10, 2010, Neil Brown wrote: On Wed, 9 Jun 2010 11:40:27 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Wednesday 09 June 2010, Felipe Contreras wrote: On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, 8 Jun 2010, da...@lang.hm wrote: having suspend blockers inside the kernel adds significant complexity, it's worth it only if the complexity buys you enough. In this case the question is if the suspend blockers would extend the sleep time enough more to matter. As per my other e-mail, this is an area with rapidly diminishing returns as the sleep times get longer. Well, the counter-argument that nobody seems to have brought up is that suspend blockers exist, are real code, and end up being shipped in a lot of machines. That's a _big_ argument in favour of them. Certainly much bigger than arguing against them based on some complexity-arguments for an alternative that hasn't seen any testing at all. IOW, I would seriously hope that this discussion was more about real code that _exists_ and does what people need. It seems to have degenerated into something else. Because in the end, code talks, bullshit walks. People can complain and suggest alternatives all they want, but you can't just argue. At some point you need to show the code that actually solves the problem. That's assuming there is an actual problem, which according to all the embedded people except android, there is not. Yes, there is, but they've decided to ignore it. And if there is indeed such a problem (probably not big), it might be solved properly by the time suspend blockers are merged, or few releases after. Not quite. Have you followed all of the discussion, actually? Whatever the solution (or workaround) is, it would be nice if it could be used by more than just android people, and it would also be nice to do it without introducing user-space API that *nobody* likes and might be quickly deprecated. I agree with Linus and I don't have that much of a problem with the API that people seem to have. In fact the much-hated user space API is just a char device driver with 3 ioctls (that can be extended in future if need be) and the kernel API is acceptable to me. I think there is a little bit more to it than that. It seems there is a new ioctl for input/event devices to say Any events queued here should be treated as wake-up events. There may be similar additions to other devices, but I know of no details. That's not in the patchset as in my pull request. It is used on Android, though, and it would have been submitted separately, had the first patchset been merged. I wonder if we can get a complete statement of changes to the user-space API... Yes, there is some overlap between it and PM QoS, but IMhO that overlap may be reduced over time (eg. by using PM QoS requirements to implement suspend blockers). To me, the question boils down to whether or not we're able to persuade the Android people to use any other approach (eg. by demonstrating that something else is actually better), because even if we invent a brilliant new approach, but Android ends up using its old one anyway, the net result will be as though we haven't done anything useful. Yes. There is no point unless we can meet somewhere in the middle. I think that would have to include a full suspend that freezes all processes. Solutions which reject that - while quite clever - would require too much change to Android user-space to be acceptable. Moreover, having thought a bit more about the power manager in user space concept I'm not sure if it really is that better than the original wakelocks idea. Namely, it only repaces a kernel-based mechanism with a user space task doing basically the same thing, but the communication between that task and the other cooperating user space tasks is arguably more complicated (it also uses the kernel resources, although indirectly). So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Thu, 10 Jun 2010 10:59:43 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Thursday, June 10, 2010, Neil Brown wrote: On Wed, 9 Jun 2010 11:40:27 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Wednesday 09 June 2010, Felipe Contreras wrote: On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, 8 Jun 2010, da...@lang.hm wrote: having suspend blockers inside the kernel adds significant complexity, it's worth it only if the complexity buys you enough. In this case the question is if the suspend blockers would extend the sleep time enough more to matter. As per my other e-mail, this is an area with rapidly diminishing returns as the sleep times get longer. Well, the counter-argument that nobody seems to have brought up is that suspend blockers exist, are real code, and end up being shipped in a lot of machines. That's a _big_ argument in favour of them. Certainly much bigger than arguing against them based on some complexity-arguments for an alternative that hasn't seen any testing at all. IOW, I would seriously hope that this discussion was more about real code that _exists_ and does what people need. It seems to have degenerated into something else. Because in the end, code talks, bullshit walks. People can complain and suggest alternatives all they want, but you can't just argue. At some point you need to show the code that actually solves the problem. That's assuming there is an actual problem, which according to all the embedded people except android, there is not. Yes, there is, but they've decided to ignore it. And if there is indeed such a problem (probably not big), it might be solved properly by the time suspend blockers are merged, or few releases after. Not quite. Have you followed all of the discussion, actually? Whatever the solution (or workaround) is, it would be nice if it could be used by more than just android people, and it would also be nice to do it without introducing user-space API that *nobody* likes and might be quickly deprecated. I agree with Linus and I don't have that much of a problem with the API that people seem to have. In fact the much-hated user space API is just a char device driver with 3 ioctls (that can be extended in future if need be) and the kernel API is acceptable to me. I think there is a little bit more to it than that. It seems there is a new ioctl for input/event devices to say Any events queued here should be treated as wake-up events. There may be similar additions to other devices, but I know of no details. That's not in the patchset as in my pull request. It is used on Android, though, and it would have been submitted separately, had the first patchset been merged. Very true. But as the one cannot be used without the other, they really need to be considered as a package. I wonder if we can get a complete statement of changes to the user-space API... Yes, there is some overlap between it and PM QoS, but IMhO that overlap may be reduced over time (eg. by using PM QoS requirements to implement suspend blockers). To me, the question boils down to whether or not we're able to persuade the Android people to use any other approach (eg. by demonstrating that something else is actually better), because even if we invent a brilliant new approach, but Android ends up using its old one anyway, the net result will be as though we haven't done anything useful. Yes. There is no point unless we can meet somewhere in the middle. I think that would have to include a full suspend that freezes all processes. Solutions which reject that - while quite clever - would require too much change to Android user-space to be acceptable. Moreover, having thought a bit more about the power manager in user space concept I'm not sure if it really is that better than the original wakelocks idea. Namely, it only repaces a kernel-based mechanism with a user space task doing basically the same thing, but the communication between that task and the other cooperating user space tasks is arguably more complicated (it also uses the kernel resources, although indirectly). So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. Following that logic would we end up putting everything in the kernel? To my mind the advantage of having something in user-space is flexibility - you can refine the interfaces and behaviours without bothering the kernel. The reasons for putting things in the kernel are: - tight integration with VM or processes (the
Re: [linux-pm] suspend blockers Android integration
On Thu, Jun 10, 2010 at 10:59:43AM +0200, Rafael J. Wysocki wrote: So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. I'm not clear where this requirement to simplify user space specifically for phones comes from - phones do have pretty substantial software stacks that aren't that far away to PCs. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Wed, 9 Jun 2010, Arve Hjønnevåg wrote: I think this is where you misunderstood. There is no report wakeup event as such. All that happens is that data becomes available to be read from the input device file. However the power manager process isn't polling the device file at this point (because a suspend blocker is active), so it doesn't realize that the source has become active again. Yes this is not what I though you were suggesting. I thought you were trying to make sure the power manager sees all wakeup events. If you are only listening for wakeup events while no suspend blockers are active, why latch them? ... If you only poll the fd after the last user-space suspend blocker is released, why do you care when the kernel wakelock could have been released? It seem the only thing it saves you is an extra poll call when two wakeup events happen at the same time and one of them is fully processed and unblocks suspend before the other event handler blocks suspend. It seems strange to remove your wakeup event from the list when a specific suspend blocker is acquired when any suspend blocker will prevent that wakeup event from being added to the list in the first place. ... I don't think there is a need to tie the fds to anything else. If you poll the fds on the last suspend unblock call, you should get the same behaviour. You are quite right; there is no need to associate suspend blockers with wakeup sources. The power manager merely needs to poll all wakeup sources whenever no suspend blockers are active. I put those associations in the proposal because of the line of reasoning that led up to it, but they aren't necessary. All input events that can wake the system are handled by one user-space suspend blocker. Input devices come and go so we would need to add and remove the fds dynamically. Correct; the power manager would need to know whenever a wakeup-capable device file was opened or closed. The power manager would indeed have to know about wakeup devices that don't need to _keep_ the system awake. Here's one way to cope: During those times when no suspend blockers are active but the PM process thinks a wakeup source is active, the PM process could poll every few seconds to update its list of active sources. At those points it could remove wakeup sources that have timed out. For that to work the wakeup events would have to be reported to the power manager in a reliable way in the first place. Passing the file descriptor that the app uses to the power manager does not work for this, since the app could read the event while the power manager was not in the poll call and the power manager would never see it. If the app activates a suspend blocker before reading the event, this doesn't matter. If the app doesn't activate a suspend blocker then it risks being suspended after it has read the event but before it has handled the event. This is equally true with wakelocks. Also, existing apps don't pass their file descriptors to the power manager, so it has the get the event from somewhere else. Now you've put your finger on the key. The main difference between my scheme and the original wakelock scheme is that programs have to inform the power manager whenever they open or close a wakeup-capable device file. With everything implemented inside the kernel this isn't necessary, because obviously a kernel driver already knows when its device file is opened or closed. As I said before, this additional complication in userspace is the price paid for keeping stuff out of the kernel. If you had implemented wakelocks this way originally, you would not have needed to patch the vanilla kernel and this entire stormy discussion would never have occurred. (But of course you couldn't have used this for the original implementation of wakelocks, because back then the hardware couldn't achieve the lowest power states from idle.) Obviously this proposal would complicate your userspace. Not enormously, since most of the work is confined to the power manager, No, the main problem it that it is not confined to the power manager. The power manager does not have a list of file descriptors to monitor, so we have to modify all code that handles wakeup events. This includes vendor supplied code that we don't have the source for, but, on some platforms at least, this code relies on kernel wakelocks with a timeout and could at first be handled the same way we would have to handle existing apps reading from a socket. Look, I never said this scheme was _better_ than wakelocks. I merely said that it could be used without significant modifications to the kernel. The suspend blocker approach is more generally useful since it supports hardware where suspend is needed. Why this argument is being ignored is very puzzling. Probably because people doesn't envision system suspend being used for dynamic power management on that kind of
Re: [linux-pm] suspend blockers Android integration
On Wed, 9 Jun 2010 da...@lang.hm wrote: why could the suspend blocker process see all events, but the power manager process not see the events? have the userspace talk to the power manager the way it does to the suspend blocker now and what's the difference? effectivly think s/suspend blocker/power manager/ (with the power manager doing all the other things that are proposed instead of grabbing the wakelock), the difference should be hidden to the rest of userspace. what am I missing here? The main difference is that with a userspace power manager, programs have to tell the power manager whenever they open or close a wakeup-capable device file (and send it a copy of the file descriptor). With an in-kernel implementation these extra steps aren't needed, because of course kernel drivers already know when their device files are opened or closed. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Thu, 10 Jun 2010, Rafael J. Wysocki wrote: Moreover, having thought a bit more about the power manager in user space concept I'm not sure if it really is that better than the original wakelocks idea. Namely, it only repaces a kernel-based mechanism with a user space task doing basically the same thing, but the communication between that task and the other cooperating user space tasks is arguably more complicated (it also uses the kernel resources, although indirectly). That is all true. The power manager in userspace was meant to prove a point: that this _could_ be done without invasive changes to the kernel. It wasn't necessarily meant to be a _better_ solution. So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. This is a judgment call. Obviously different people have different opinions. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Thursday, June 10, 2010, Alan Stern wrote: On Thu, 10 Jun 2010, Rafael J. Wysocki wrote: Moreover, having thought a bit more about the power manager in user space concept I'm not sure if it really is that better than the original wakelocks idea. Namely, it only repaces a kernel-based mechanism with a user space task doing basically the same thing, but the communication between that task and the other cooperating user space tasks is arguably more complicated (it also uses the kernel resources, although indirectly). That is all true. The power manager in userspace was meant to prove a point: that this _could_ be done without invasive changes to the kernel. It wasn't necessarily meant to be a _better_ solution. So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. This is a judgment call. Obviously different people have different opinions. Agreed. Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Thursday, June 10, 2010, Mark Brown wrote: On Thu, Jun 10, 2010 at 10:59:43AM +0200, Rafael J. Wysocki wrote: So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. I'm not clear where this requirement to simplify user space specifically for phones comes from This isn't a requirement, but something that IMO is reasonable. - phones do have pretty substantial software stacks that aren't that far away to PCs. That doesn't seem to be relevant here. Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Thursday, June 10, 2010, Neil Brown wrote: On Thu, 10 Jun 2010 10:59:43 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Thursday, June 10, 2010, Neil Brown wrote: On Wed, 9 Jun 2010 11:40:27 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Wednesday 09 June 2010, Felipe Contreras wrote: On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, 8 Jun 2010, da...@lang.hm wrote: having suspend blockers inside the kernel adds significant complexity, it's worth it only if the complexity buys you enough. In this case the question is if the suspend blockers would extend the sleep time enough more to matter. As per my other e-mail, this is an area with rapidly diminishing returns as the sleep times get longer. Well, the counter-argument that nobody seems to have brought up is that suspend blockers exist, are real code, and end up being shipped in a lot of machines. That's a _big_ argument in favour of them. Certainly much bigger than arguing against them based on some complexity-arguments for an alternative that hasn't seen any testing at all. IOW, I would seriously hope that this discussion was more about real code that _exists_ and does what people need. It seems to have degenerated into something else. Because in the end, code talks, bullshit walks. People can complain and suggest alternatives all they want, but you can't just argue. At some point you need to show the code that actually solves the problem. That's assuming there is an actual problem, which according to all the embedded people except android, there is not. Yes, there is, but they've decided to ignore it. And if there is indeed such a problem (probably not big), it might be solved properly by the time suspend blockers are merged, or few releases after. Not quite. Have you followed all of the discussion, actually? Whatever the solution (or workaround) is, it would be nice if it could be used by more than just android people, and it would also be nice to do it without introducing user-space API that *nobody* likes and might be quickly deprecated. I agree with Linus and I don't have that much of a problem with the API that people seem to have. In fact the much-hated user space API is just a char device driver with 3 ioctls (that can be extended in future if need be) and the kernel API is acceptable to me. I think there is a little bit more to it than that. It seems there is a new ioctl for input/event devices to say Any events queued here should be treated as wake-up events. There may be similar additions to other devices, but I know of no details. That's not in the patchset as in my pull request. It is used on Android, though, and it would have been submitted separately, had the first patchset been merged. Very true. But as the one cannot be used without the other, they really need to be considered as a package. You can use suspend blockers as in the pull request without the input patch in principle. I wonder if we can get a complete statement of changes to the user-space API... Yes, there is some overlap between it and PM QoS, but IMhO that overlap may be reduced over time (eg. by using PM QoS requirements to implement suspend blockers). To me, the question boils down to whether or not we're able to persuade the Android people to use any other approach (eg. by demonstrating that something else is actually better), because even if we invent a brilliant new approach, but Android ends up using its old one anyway, the net result will be as though we haven't done anything useful. Yes. There is no point unless we can meet somewhere in the middle. I think that would have to include a full suspend that freezes all processes. Solutions which reject that - while quite clever - would require too much change to Android user-space to be acceptable. Moreover, having thought a bit more about the power manager in user space concept I'm not sure if it really is that better than the original wakelocks idea. Namely, it only repaces a kernel-based mechanism with a user space task doing basically the same thing, but the communication between that task and the other cooperating user space tasks is arguably more complicated (it also uses the kernel resources, although indirectly). So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. Following that logic would we end up
Re: [linux-pm] suspend blockers Android integration
On Thu, Jun 10, 2010 at 05:46:46PM +0200, Rafael J. Wysocki wrote: On Thursday, June 10, 2010, Mark Brown wrote: On Thu, Jun 10, 2010 at 10:59:43AM +0200, Rafael J. Wysocki wrote: So, for a phone-like system, where you'd generally want to simplify user space, having a power manager in the kernel seems to make sense to me. I'm not clear where this requirement to simplify user space specifically for phones comes from This isn't a requirement, but something that IMO is reasonable. - phones do have pretty substantial software stacks that aren't that far away to PCs. That doesn't seem to be relevant here. Sure, that's my point - you seem to be suggesting that phones have a different requirement here. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/10 Alan Stern st...@rowland.harvard.edu: On Wed, 9 Jun 2010, Arve Hjønnevåg wrote: I think this is where you misunderstood. There is no report wakeup event as such. All that happens is that data becomes available to be read from the input device file. However the power manager process isn't polling the device file at this point (because a suspend blocker is active), so it doesn't realize that the source has become active again. Yes this is not what I though you were suggesting. I thought you were trying to make sure the power manager sees all wakeup events. If you are only listening for wakeup events while no suspend blockers are active, why latch them? ... If you only poll the fd after the last user-space suspend blocker is released, why do you care when the kernel wakelock could have been released? It seem the only thing it saves you is an extra poll call when two wakeup events happen at the same time and one of them is fully processed and unblocks suspend before the other event handler blocks suspend. It seems strange to remove your wakeup event from the list when a specific suspend blocker is acquired when any suspend blocker will prevent that wakeup event from being added to the list in the first place. ... I don't think there is a need to tie the fds to anything else. If you poll the fds on the last suspend unblock call, you should get the same behaviour. You are quite right; there is no need to associate suspend blockers with wakeup sources. The power manager merely needs to poll all wakeup sources whenever no suspend blockers are active. I put those associations in the proposal because of the line of reasoning that led up to it, but they aren't necessary. All input events that can wake the system are handled by one user-space suspend blocker. Input devices come and go so we would need to add and remove the fds dynamically. Correct; the power manager would need to know whenever a wakeup-capable device file was opened or closed. The power manager would indeed have to know about wakeup devices that don't need to _keep_ the system awake. Here's one way to cope: During those times when no suspend blockers are active but the PM process thinks a wakeup source is active, the PM process could poll every few seconds to update its list of active sources. At those points it could remove wakeup sources that have timed out. For that to work the wakeup events would have to be reported to the power manager in a reliable way in the first place. Passing the file descriptor that the app uses to the power manager does not work for this, since the app could read the event while the power manager was not in the poll call and the power manager would never see it. If the app activates a suspend blocker before reading the event, this doesn't matter. If the app doesn't activate a suspend blocker then it risks being suspended after it has read the event but before it has handled the event. This is equally true with wakelocks. It is not the same. Using a wakelock with a timeout only has a problem if the app did not get a change to run and block suspend before the timeout expires. With the timeout values we use there is only a problem if the system is already unresponsive. If the driver does not block suspend but instead a power manager calls select or poll on a file descriptor while the app does a blocking read, the power manager can easily miss the event and suspend before the app blocks suspend. Also, existing apps don't pass their file descriptors to the power manager, so it has the get the event from somewhere else. Now you've put your finger on the key. The main difference between my scheme and the original wakelock scheme is that programs have to inform the power manager whenever they open or close a wakeup-capable device file. With everything implemented inside the kernel this isn't necessary, because obviously a kernel driver already knows when its device file is opened or closed. As I said before, this additional complication in userspace is the price paid for keeping stuff out of the kernel. If you had implemented wakelocks this way originally, you would not have needed to patch the vanilla kernel and this entire stormy discussion would never have occurred. (But of course you couldn't have used this for the original implementation of wakelocks, because back then the hardware couldn't achieve the lowest power states from idle.) Obviously this proposal would complicate your userspace. Not enormously, since most of the work is confined to the power manager, No, the main problem it that it is not confined to the power manager. The power manager does not have a list of file descriptors to monitor, so we have to modify all code that handles wakeup events. This includes vendor supplied code that we don't have the source for, but, on some platforms at least, this code relies on kernel
Re: [linux-pm] suspend blockers Android integration
On Thu, 10 Jun 2010, Arve Hjønnevåg wrote: For that to work the wakeup events would have to be reported to the power manager in a reliable way in the first place. Passing the file descriptor that the app uses to the power manager does not work for this, since the app could read the event while the power manager was not in the poll call and the power manager would never see it. If the app activates a suspend blocker before reading the event, this doesn't matter. If the app doesn't activate a suspend blocker then it risks being suspended after it has read the event but before it has handled the event. This is equally true with wakelocks. It is not the same. Using a wakelock with a timeout only has a problem if the app did not get a change to run and block suspend before the timeout expires. With the timeout values we use there is only a problem if the system is already unresponsive. If the driver does not block suspend but instead a power manager calls select or poll on a file descriptor while the app does a blocking read, the power manager can easily miss the event and suspend before the app blocks suspend. You've lost me. If the power manager is sitting inside a select/poll, how can it miss the event (given that the event will make data available to be read on one of the descriptors being polled)? Or put it another way: With wakelocks, if the app doesn't use a suspend blocker then once it reads the event data and the timed wakelock is deactivated, there is nothing to prevent the system from immediately going into opportunistic suspend. My scheme can fail in the same way. Is that what you meant? The suspend blocker approach is more generally useful since it supports hardware where suspend is needed. Why this argument is being ignored is very puzzling. Probably because people doesn't envision system suspend being used for dynamic power management on that kind of hardware. I'm not sure what you mean by dynamic power management here (frequency of suspends?), but auto suspend is already in use on x86 desktops and laptops. Suspend blockers can fix the race with some wakeup events there. You should stress this point more strongly when conversing with others. I doubt it will be enough to change anybody's mind, but it can't hurt. Indeed, if you propose suspend blockers as a way to fix a lost-wakeup bug in existing distributions, rather than as something needed to support Android, people might view it more favorably. There's one question that I don't remember ever seeing answered. To which kernel drivers do you intend to add suspend blockers? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/10 Alan Stern st...@rowland.harvard.edu: On Thu, 10 Jun 2010, Arve Hjønnevåg wrote: For that to work the wakeup events would have to be reported to the power manager in a reliable way in the first place. Passing the file descriptor that the app uses to the power manager does not work for this, since the app could read the event while the power manager was not in the poll call and the power manager would never see it. If the app activates a suspend blocker before reading the event, this doesn't matter. If the app doesn't activate a suspend blocker then it risks being suspended after it has read the event but before it has handled the event. This is equally true with wakelocks. It is not the same. Using a wakelock with a timeout only has a problem if the app did not get a change to run and block suspend before the timeout expires. With the timeout values we use there is only a problem if the system is already unresponsive. If the driver does not block suspend but instead a power manager calls select or poll on a file descriptor while the app does a blocking read, the power manager can easily miss the event and suspend before the app blocks suspend. You've lost me. If the power manager is sitting inside a select/poll, how can it miss the event (given that the event will make data available to be read on one of the descriptors being polled)? It cannot sit inside of select/poll all the time. Or put it another way: With wakelocks, if the app doesn't use a suspend blocker then once it reads the event data and the timed wakelock is deactivated, there is nothing to prevent the system from immediately going into opportunistic suspend. My scheme can fail in the same way. Is that what you meant? No, if an app reads from a file descriptor and block suspend when the read call returns, then suspend is blocked while processing the data. If the driver uses a wakelock with a timeout this will fail if the thread does not get to the suspend block call before the timeout expires, but unrelated events that don't prevent the app from running will not cause any problems. In your scheme the user-space power manager may miss events on this file descriptor since select/poll will not see an event if the app read that event right before the power manager called select/poll. The suspend blocker approach is more generally useful since it supports hardware where suspend is needed. Why this argument is being ignored is very puzzling. Probably because people doesn't envision system suspend being used for dynamic power management on that kind of hardware. I'm not sure what you mean by dynamic power management here (frequency of suspends?), but auto suspend is already in use on x86 desktops and laptops. Suspend blockers can fix the race with some wakeup events there. You should stress this point more strongly when conversing with others. I doubt it will be enough to change anybody's mind, but it can't hurt. Indeed, if you propose suspend blockers as a way to fix a lost-wakeup bug in existing distributions, rather than as something needed to support Android, people might view it more favorably. There's one question that I don't remember ever seeing answered. To which kernel drivers do you intend to add suspend blockers? All drivers that generate wakeup events need to either use suspend blockers directly or call into something else that does. For instance, with the patch to block suspend while input events are queued to user-space, an input driver that fully handles its events in its interrupt handler does not need any additional suspend blockers, but if the driver needs a work function or a timer to run before it reports the event it needs to block suspend until it has reported the event. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
This is a bit off the topic of Android flamage, but I thought it would be worth highlighting an example where the current frameworks may still have a deficiency... one that likewise relates to needing to block entry ot a system suspend state, but in this case user-space isn't very involved (just drivers coping with hardware). The example I wanted to re-post (I've done so in the past) is one where drivers ouldn't really do the right thing, since driver.suspend() wasn't quite powerful enough as a programming interface. The example works with USB on many ARM SoCs, and similar non-USB examples aren't rare. - Want to enter a system suspend state, with some USB wakeup sources. USB peripheral waken up by the host, or vice versa. NOTE ASSUMPTION: there are multiple suspend states supported by the hardware, significantly different in hardware configuration Linux should be able to use more than one such state... (if only because their power savings differ.) This can mean driver-specific knowledge about those various states. - The wakeup requires a particular clock to be active, so the USB controller can detect that the wakeup should trigger, then issue the right signals triggering the non-USB parts of the system. Problem: how does the device driver suspend() method block entry to a suspend state when it can't ensure that clock is going to be active. Magic return code? There are other issues here too. (Is the target system suspend state one of the ones which doesn't allow that clock to be active? SoC-specific calls might suffice for this issue. A number of years ago, this problem was insoluble with the then-current Linux PM and clock frameworks. I've been away from this issue for quite a while now, but don't recall seeing its sub-problems get solved ... If they're now solved, I'll be glad. (I know Kevin's recent OMAP stuff addresses similar issues, but It's OMAP-specific...) After all these thousands and thousands of emails... I'm not sure how much forward motion has happened. Do we at least have a clean way that a driver can reject a system suspend? I've lost track of many issues, but maybe this could be phrased as a QOS constraint: the current config of driver X needs clock Y active to enter the target system suspend state, driver's suspend() method reports as much. Then the entry to that system state gets blocked if the clock isn't enabled. (That QOS constraint should be removed when that driver no longer needs to issue wakeups; that's not quite the same as removed by driver.resume(). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, 8 Jun 2010, da...@lang.hm wrote: having suspend blockers inside the kernel adds significant complexity, it's worth it only if the complexity buys you enough. In this case the question is if the suspend blockers would extend the sleep time enough more to matter. As per my other e-mail, this is an area with rapidly diminishing returns as the sleep times get longer. Well, the counter-argument that nobody seems to have brought up is that suspend blockers exist, are real code, and end up being shipped in a lot of machines. That's a _big_ argument in favour of them. Certainly much bigger than arguing against them based on some complexity-arguments for an alternative that hasn't seen any testing at all. IOW, I would seriously hope that this discussion was more about real code that _exists_ and does what people need. It seems to have degenerated into something else. Because in the end, code talks, bullshit walks. People can complain and suggest alternatives all they want, but you can't just argue. At some point you need to show the code that actually solves the problem. That's assuming there is an actual problem, which according to all the embedded people except android, there is not. And if there is indeed such a problem (probably not big), it might be solved properly by the time suspend blockers are merged, or few releases after. Whatever the solution (or workaround) is, it would be nice if it could be used by more than just android people, and it would also be nice to do it without introducing user-space API that *nobody* likes and might be quickly deprecated. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Wednesday 09 June 2010, Felipe Contreras wrote: On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, 8 Jun 2010, da...@lang.hm wrote: having suspend blockers inside the kernel adds significant complexity, it's worth it only if the complexity buys you enough. In this case the question is if the suspend blockers would extend the sleep time enough more to matter. As per my other e-mail, this is an area with rapidly diminishing returns as the sleep times get longer. Well, the counter-argument that nobody seems to have brought up is that suspend blockers exist, are real code, and end up being shipped in a lot of machines. That's a _big_ argument in favour of them. Certainly much bigger than arguing against them based on some complexity-arguments for an alternative that hasn't seen any testing at all. IOW, I would seriously hope that this discussion was more about real code that _exists_ and does what people need. It seems to have degenerated into something else. Because in the end, code talks, bullshit walks. People can complain and suggest alternatives all they want, but you can't just argue. At some point you need to show the code that actually solves the problem. That's assuming there is an actual problem, which according to all the embedded people except android, there is not. Yes, there is, but they've decided to ignore it. And if there is indeed such a problem (probably not big), it might be solved properly by the time suspend blockers are merged, or few releases after. Not quite. Have you followed all of the discussion, actually? Whatever the solution (or workaround) is, it would be nice if it could be used by more than just android people, and it would also be nice to do it without introducing user-space API that *nobody* likes and might be quickly deprecated. I agree with Linus and I don't have that much of a problem with the API that people seem to have. In fact the much-hated user space API is just a char device driver with 3 ioctls (that can be extended in future if need be) and the kernel API is acceptable to me. Yes, there is some overlap between it and PM QoS, but IMhO that overlap may be reduced over time (eg. by using PM QoS requirements to implement suspend blockers). To me, the question boils down to whether or not we're able to persuade the Android people to use any other approach (eg. by demonstrating that something else is actually better), because even if we invent a brilliant new approach, but Android ends up using its old one anyway, the net result will be as though we haven't done anything useful. Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote: On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig h...@infradead.org wrote: On the other hand I've heard that various hardware vendors or parties closed to them are rather annoyed by their drivers beeing stuck in the android tree - but that can be easily solved by getting removing the suspend blockers (at least temporarily), cleaning up a few bits here and there and getting them in. This continues to baffle me. If we (Google) are such a headache, why not just route around us. The drivers we've written are GPLv2, the source is out there for anyone who wants it, etc. The drivers other people have written we have no control over at all. From my point of view it'd be an annoyance if somebody took the code we wrote, modified it heavily, and pushed it upstream, but fundamentally I can't stop that from happening other than by pushing it upstream myself, first. AFAICT this is purely down to the fact that the vendors producing Android devices are using the kernel which is shipped with whatever release they are using so people doing drivers end up getting locked in to an older kernel with old APIs (independant of Android specifics) and don't have the resource to redo things for upstream. Suspend blockers are one more API update in there, but general kernel development creates far more. I was looking at this just today and one thing that it occurs to me might help is if when you guys rebase your work against upstream you were to tag the results - at the minute the only release Android kernels are those included in full stack releases so providing more hints that other kernel versions could be substituted in may help. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Tue, 8 Jun 2010, Arve Hjønnevåg wrote: Wakeup event occurs, and the driver: - report wakeup event type A - queue event for delivery to user-space That's not really two distinct steps. Queuing the event for delivery to userspace involves waking up any tasks that are waiting to read the device file; that action (calling wake_up_all() or whatever the driver does) is how the event gets reported. If you want to ensure that more than one process see the event it has to be two steps, but it does not affect the race I was trying to describe. Are you sure about that? If two processes call poll() for the same file descriptor, don't both calls return when data becomes available? But agreed, it doesn't matter -- especially since I only need one process (the power manager) to see the event. User space wakes up: - Calls api to block task freezing for event type A Again, that's a confusing way of putting it. The API you're referring to is simply the function that activates a suspend blocker. It does prevent task freezing, but you shouldn't say it prevents freezing for event type A. More like the other way around: In addition to preventing freezing, the function tells the power manager that event type A should no longer be considered active. Thus, in a sense it _stops_ event type A from preventing freezing. Another wakeup event occurs, and the driver: - report wakeup event type A I think this is where you misunderstood. There is no report wakeup event as such. All that happens is that data becomes available to be read from the input device file. However the power manager process isn't polling the device file at this point (because a suspend blocker is active), so it doesn't realize that the source has become active again. - queue event for delivery to user-space Same as above. User space continues: - Read events Sorry, I missed the unblock task freezing step here. - Wait for more events Result: Task are not frozen again. Because the suspend blocker was never deactivated. The same thing happens with wakelocks: If a task activates a wakelock and never deactivates it, the system won't go into opportunistic suspend again. Yes, but with the sequence of events above task will not be frozen again even if the wake-lock/suspend-blocker/task-freezing-preventer is released. Yes they will. When the suspend blocker is deactivated, the power manager process will realize that there are no active suspend blockers and it will think there are no active sources. Thus it will freeze processes as usual. Here's how my scheme is meant to work: Wakeup event for input device A occurs. A's driver adds an entry to the input device queue and (if the queue was empty) does wake_up_all() on the device file's wait_queue. The PM process returns from poll() and sees that device file A is now readable, so it adds A to its list of active sources and unfreezes userspace. Some other process sees that device file A is now readable, so it activates a suspend blocker and reads events from A. When the PM process receives the request to activate the suspend blocker, it removes A from its list of active sources. But it doesn't freeze userspace yet, because now a suspend blocker is active. If another event happens at this point don't you put A back on the list? If so, it never gets removed. No, you don't put A back on the list. Sources get put on the list only when the information returned by poll() indicates they have data available. The power manager doesn't poll while suspend blockers are active. The other process consumes events from A and does other stuff. Maybe more input data arrives while this is happening and the process reads it. Eventually the process decides to deactivate the suspend blocker, perhaps when no more data is available from the device file, perhaps not. When the PM process receives the request to deactivate the suspend blocker, it sees that now there are no active sources and no active suspend blockers. Therefore it freezes userspace and does a big poll() on all possible sources. (If there are still events on the input device queue, the poll() returns immediately.) Rinse and repeat. I don't see any dangerous races there. The scheme can be made a little more efficient by having the PM process do another poll() (with 0 timeout) just before freezing userspace; if the result indicates that a source is active then the freezing and unfreezing can be skipped. There is no race. The driver reports an event has occurred by making the data available to be read from the device file, and the event is processed by reading it from the device file (or at least, that's the
Re: [linux-pm] suspend blockers Android integration
On Wed, 9 Jun 2010 11:40:27 +0200 Rafael J. Wysocki r...@sisk.pl wrote: On Wednesday 09 June 2010, Felipe Contreras wrote: On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, 8 Jun 2010, da...@lang.hm wrote: having suspend blockers inside the kernel adds significant complexity, it's worth it only if the complexity buys you enough. In this case the question is if the suspend blockers would extend the sleep time enough more to matter. As per my other e-mail, this is an area with rapidly diminishing returns as the sleep times get longer. Well, the counter-argument that nobody seems to have brought up is that suspend blockers exist, are real code, and end up being shipped in a lot of machines. That's a _big_ argument in favour of them. Certainly much bigger than arguing against them based on some complexity-arguments for an alternative that hasn't seen any testing at all. IOW, I would seriously hope that this discussion was more about real code that _exists_ and does what people need. It seems to have degenerated into something else. Because in the end, code talks, bullshit walks. People can complain and suggest alternatives all they want, but you can't just argue. At some point you need to show the code that actually solves the problem. That's assuming there is an actual problem, which according to all the embedded people except android, there is not. Yes, there is, but they've decided to ignore it. And if there is indeed such a problem (probably not big), it might be solved properly by the time suspend blockers are merged, or few releases after. Not quite. Have you followed all of the discussion, actually? Whatever the solution (or workaround) is, it would be nice if it could be used by more than just android people, and it would also be nice to do it without introducing user-space API that *nobody* likes and might be quickly deprecated. I agree with Linus and I don't have that much of a problem with the API that people seem to have. In fact the much-hated user space API is just a char device driver with 3 ioctls (that can be extended in future if need be) and the kernel API is acceptable to me. I think there is a little bit more to it than that. It seems there is a new ioctl for input/event devices to say Any events queued here should be treated as wake-up events. There may be similar additions to other devices, but I know of no details. I wonder if we can get a complete statement of changes to the user-space API... Yes, there is some overlap between it and PM QoS, but IMhO that overlap may be reduced over time (eg. by using PM QoS requirements to implement suspend blockers). To me, the question boils down to whether or not we're able to persuade the Android people to use any other approach (eg. by demonstrating that something else is actually better), because even if we invent a brilliant new approach, but Android ends up using its old one anyway, the net result will be as though we haven't done anything useful. Yes. There is no point unless we can meet somewhere in the middle. I think that would have to include a full suspend that freezes all processes. Solutions which reject that - while quite clever - would require too much change to Android user-space to be acceptable. NeilBrown Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/9 Alan Stern st...@rowland.harvard.edu: On Tue, 8 Jun 2010, Arve Hjønnevåg wrote: Wakeup event occurs, and the driver: - report wakeup event type A - queue event for delivery to user-space That's not really two distinct steps. Queuing the event for delivery to userspace involves waking up any tasks that are waiting to read the device file; that action (calling wake_up_all() or whatever the driver does) is how the event gets reported. If you want to ensure that more than one process see the event it has to be two steps, but it does not affect the race I was trying to describe. Are you sure about that? If two processes call poll() for the same file descriptor, don't both calls return when data becomes available? Yes if they are both already in the poll call they both return, but if one process reads the data while the second process is not in the poll call the second process will not see anything. But agreed, it doesn't matter -- especially since I only need one process (the power manager) to see the event. The power may not see the event, the process that reads the event will always see it. If the power manager is not in the poll call when the event happens, the process that reads the event can read the event before the power manager calls poll. User space wakes up: - Calls api to block task freezing for event type A Again, that's a confusing way of putting it. The API you're referring to is simply the function that activates a suspend blocker. It does prevent task freezing, but you shouldn't say it prevents freezing for event type A. More like the other way around: In addition to preventing freezing, the function tells the power manager that event type A should no longer be considered active. Thus, in a sense it _stops_ event type A from preventing freezing. Another wakeup event occurs, and the driver: - report wakeup event type A I think this is where you misunderstood. There is no report wakeup event as such. All that happens is that data becomes available to be read from the input device file. However the power manager process isn't polling the device file at this point (because a suspend blocker is active), so it doesn't realize that the source has become active again. Yes this is not what I though you were suggesting. I thought you were trying to make sure the power manager sees all wakeup events. If you are only listening for wakeup events while no suspend blockers are active, why latch them? - queue event for delivery to user-space Same as above. User space continues: - Read events Sorry, I missed the unblock task freezing step here. - Wait for more events Result: Task are not frozen again. Because the suspend blocker was never deactivated. The same thing happens with wakelocks: If a task activates a wakelock and never deactivates it, the system won't go into opportunistic suspend again. Yes, but with the sequence of events above task will not be frozen again even if the wake-lock/suspend-blocker/task-freezing-preventer is released. Yes they will. When the suspend blocker is deactivated, the power manager process will realize that there are no active suspend blockers and it will think there are no active sources. Thus it will freeze processes as usual. Here's how my scheme is meant to work: Wakeup event for input device A occurs. A's driver adds an entry to the input device queue and (if the queue was empty) does wake_up_all() on the device file's wait_queue. The PM process returns from poll() and sees that device file A is now readable, so it adds A to its list of active sources and unfreezes userspace. Some other process sees that device file A is now readable, so it activates a suspend blocker and reads events from A. When the PM process receives the request to activate the suspend blocker, it removes A from its list of active sources. But it doesn't freeze userspace yet, because now a suspend blocker is active. If another event happens at this point don't you put A back on the list? If so, it never gets removed. No, you don't put A back on the list. Sources get put on the list only when the information returned by poll() indicates they have data available. The power manager doesn't poll while suspend blockers are active. The other process consumes events from A and does other stuff. Maybe more input data arrives while this is happening and the process reads it. Eventually the process decides to deactivate the suspend blocker, perhaps when no more data is available from the device file, perhaps not. When the PM process receives the request to deactivate the suspend blocker, it sees that now there are no active sources and no active suspend blockers.
Re: [linux-pm] suspend blockers Android integration
On Wed, 9 Jun 2010, Arve Hj?nnev?g wrote: The power may not see the event, the process that reads the event will always see it. If the power manager is not in the poll call when the event happens, the process that reads the event can read the event before the power manager calls poll. All input events that can wake the system are handled by one user-space suspend blocker. Input devices come and go so we would need to add and remove the fds dynamically. For that to work the wakeup events would have to be reported to the power manager in a reliable way in the first place. Passing the file descriptor that the app uses to the power manager does not work for this, since the app could read the event while the power manager was not in the poll call and the power manager would never see it. Also, existing apps don't pass their file descriptors to the power manager, so it has the get the event from somewhere else. why could the suspend blocker process see all events, but the power manager process not see the events? have the userspace talk to the power manager the way it does to the suspend blocker now and what's the difference? effectivly think s/suspend blocker/power manager/ (with the power manager doing all the other things that are proposed instead of grabbing the wakelock), the difference should be hidden to the rest of userspace. what am I missing here? David Lang -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/9 da...@lang.hm: On Wed, 9 Jun 2010, Arve Hj?nnev?g wrote: The power may not see the event, the process that reads the event will always see it. If the power manager is not in the poll call when the event happens, the process that reads the event can read the event before the power manager calls poll. All input events that can wake the system are handled by one user-space suspend blocker. Input devices come and go so we would need to add and remove the fds dynamically. For that to work the wakeup events would have to be reported to the power manager in a reliable way in the first place. Passing the file descriptor that the app uses to the power manager does not work for this, since the app could read the event while the power manager was not in the poll call and the power manager would never see it. Also, existing apps don't pass their file descriptors to the power manager, so it has the get the event from somewhere else. why could the suspend blocker process see all events, but the power manager process not see the events? Because in this proposal the power manager only looks for the events (on the same queue) when no user space suspend blockers are active. have the userspace talk to the power manager the way it does to the suspend blocker now and what's the difference? effectivly think s/suspend blocker/power manager/ (with the power manager doing all the other things that are proposed instead of grabbing the wakelock), the difference should be hidden to the rest of userspace. what am I missing here? The current user space interface does not require that clients register the file descriptors that they get wakeup events from with another process. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Wed, 9 Jun 2010 21:51:38 -0700 Arve Hjønnevåg a...@android.com wrote: The current user space interface does not require that clients register the file descriptors that they get wakeup events from with another process. However I believe they *do* register these file descriptors with the kernel, via some sort of ioctl (I think you have said that is the case for input devices at least). Can you confirm that? If that is the case, is it really such a big change to register with another process instead of with the kernel? Thanks, NeilBrown -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Mon, 7 Jun 2010 20:05:56 -0700 Arve Hjønnevåg a...@android.com wrote: Hi, If you read an event that occurred after you blocked the task freezing, then tasks will never get frozen again (until more events occur). I think my original description was less confusing, but it seems you got completely distracted by my use of block and unblock suspend when referring to the user space api. Here is how I understood Alan's approach: Userspace manager (UM) does: ...continuation of function A 5) unblock from reading a wakeup from wakeupevents-fd 6) thaw userspace 7) return /function A [userspace sees there is an event; blocks suspend at UM; processes event; consume wakeupevent at UM; unblock suspend at UM;] Unblocking the last suspend-blocker at the UM starts function A: function A 1) non-blocking read of wakeup-events-fd (refills wakeupevents) 2) if all wakeupevents are consumed: 3a) freeze userspace else 3b) /* wait for userspace to unblock suspend again... this should take care of the races? */ return; 4) blocking read of wakeupevents-fd ...for continuation see above You mitigate the race by freezing and unfreezing userspace. If there occur wakeups between 3a) and 4) you will have frozen userspace in vain. So I think the feasibility of this solution depends on the performance of freezing/thawing userspace. I can't judge that. Also I _think_ this is racefree as long as you have the UM properly serialized. Or did I overlook something? Cheers, Flo -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote: The patch that modifies evdev (posted in this patchset) uses an ioctl to enable the suspend blocker. Not all input devices are used for wakeup events and those don't need to block suspend. But you do have a 1-1 correspondence, right? That is, the input devices that are used for wakeup events are exactly the ones that block suspend? If you read an event that occurred after you blocked the task freezing, then tasks will never get frozen again (until more events occur). I think my original description was less confusing, but it seems you got completely distracted by my use of block and unblock suspend when referring to the user space api. I still find your wording a little confusing. Task freezing can be prevented (a more accurate term than blocked) by two kinds of things: a suspend blocker or an active wakeup source. I'm not sure which kind you mean here. It has an indirect connection. You report a wakeup event when it occurs, but clear it when user space calls an api before reading the event. So: Yes, that's right. Wakeup event occurs, and the driver: - report wakeup event type A - queue event for delivery to user-space That's not really two distinct steps. Queuing the event for delivery to userspace involves waking up any tasks that are waiting to read the device file; that action (calling wake_up_all() or whatever the driver does) is how the event gets reported. User space wakes up: - Calls api to block task freezing for event type A Again, that's a confusing way of putting it. The API you're referring to is simply the function that activates a suspend blocker. It does prevent task freezing, but you shouldn't say it prevents freezing for event type A. More like the other way around: In addition to preventing freezing, the function tells the power manager that event type A should no longer be considered active. Thus, in a sense it _stops_ event type A from preventing freezing. Another wakeup event occurs, and the driver: - report wakeup event type A - queue event for delivery to user-space Same as above. User space continues: - Read events - Wait for more events Result: Task are not frozen again. Because the suspend blocker was never deactivated. The same thing happens with wakelocks: If a task activates a wakelock and never deactivates it, the system won't go into opportunistic suspend again. Here's how my scheme is meant to work: Wakeup event for input device A occurs. A's driver adds an entry to the input device queue and (if the queue was empty) does wake_up_all() on the device file's wait_queue. The PM process returns from poll() and sees that device file A is now readable, so it adds A to its list of active sources and unfreezes userspace. Some other process sees that device file A is now readable, so it activates a suspend blocker and reads events from A. When the PM process receives the request to activate the suspend blocker, it removes A from its list of active sources. But it doesn't freeze userspace yet, because now a suspend blocker is active. The other process consumes events from A and does other stuff. Maybe more input data arrives while this is happening and the process reads it. Eventually the process decides to deactivate the suspend blocker, perhaps when no more data is available from the device file, perhaps not. When the PM process receives the request to deactivate the suspend blocker, it sees that now there are no active sources and no active suspend blockers. Therefore it freezes userspace and does a big poll() on all possible sources. (If there are still events on the input device queue, the poll() returns immediately.) Rinse and repeat. I don't see any dangerous races there. The scheme can be made a little more efficient by having the PM process do another poll() (with 0 timeout) just before freezing userspace; if the result indicates that a source is active then the freezing and unfreezing can be skipped. The big assumption here is that a user process never consumes wakeup events without first activating a suspend blocker. This seems like a reasonable assumption, but we can work around it if necessary. It seems you would need a way to pass the wakeup source id to use from user space to the driver and for this to work No, nothing needs to be passed from userspace to the kernel. However the source ID (or a set of source IDs) does need to be passed to the power manager process, probably when the suspend blocker is created. Then the source id need to be passed from the kernel to user-space. A source ID is a file descriptor. File descriptors are passed from the kernel to userspace whenever a file is opened; I can't deny it. And they are passed
Re: [linux-pm] suspend blockers Android integration
On Mon, 7 Jun 2010, Florian Mickler wrote: On Sun, 6 Jun 2010 04:14:09 -0700 (PDT) da...@lang.hm wrote: On Sun, 6 Jun 2010, Florian Mickler wrote: On Sun, 6 Jun 2010 12:19:08 +0200 Vitaly Wool vitalyw...@gmail.com wrote: 2010/6/6 da...@lang.hm: as an example (taken from this thread). system A needs to wake up to get a battery reading, store it and go back to sleep, It does so every 10 seconds. But when it does so it only runs the one process and then goes back to sleep. system B has the same need, but wakes up every 10 minutes. but when it does so it fully wakes up and this allows the mail app to power up the radio, connect to the Internet and start checking for new mail before oppurtunistic sleep shuts things down (causing the mail check to fail) System A will last considerably longer on a battery than System B. Exactly, thanks for pointing out the specific example :) ~Vitaly This does not affect suspend_blockers nor does suspend_blockers interfere with that. Suspend_blockers allow the system to suspend (mem/sys/power/state suspend), when the userspace decides that the device is not in use. So implementing suspend_blockers support does not impact any optimizations done to either system A nor system B. Actually, it does. system A is what's being proposed by kernel developers, where the untrusted stuff is in a different cgroup and what puts the system to sleep is 'normal' power management. It doesn't sleep as long, but when it wakes up the untrusted stuff is still frozen, so it doesn't stay awake long, or do very much. System B is suspend blockers where you are either awake or asleep, and when you wake up you wake up fully, but oppertunistic sleep can interrupt untrusted processes at any time. The system sleeps longer (as fewer things can wake it), but when it wakes up it's fully awake. David Lang You say, that coming back from suspend takes the system to full power (and everything runs) before it begins the descend into runtime-low-power? But are you referring to the fact that coming back from suspend starts in the zero-idle-state (i.e. consumes extra power) or that all processes run when it is not suspended? I am referring to the fact that with suspend blockers and opertunistic suspend all processes start running when it's not suspended (because they were all running when it was suspended) If instead the system only wakes up the trusted processes to handle whatever woke the system up and is then idle again, it spends less power and time while awake. Because the latter would of course (theretically) profit from the framework-controlled-cgroup-freeze/thaw (with and without opportunistic suspend) while the former should be a problem that both opportunistic suspend as well as suspend-from-idle have. Or not? So, here is the question I'm asking myself: If System A were to be complemented by suspend_blockers, wouldn't it still be better? not neccessarily. having suspend blockers inside the kernel adds significant complexity, it's worth it only if the complexity buys you enough. In this case the question is if the suspend blockers would extend the sleep time enough more to matter. As per my other e-mail, this is an area with rapidly diminishing returns as the sleep times get longer. With System A you could try to do a really sophisticated power-management scheme and so on... but as soon as you allow 3rd-Party Apps, how do you manage their cross-dependencies? I.e. you can not automatically detect when App1 needs App2 to function. You need to allow all 3rd-Party apps to run as a group. So you can perhaps partition your software stack into untrusted applications and different groups of software with audited dependencies. If one group interacts with another group (as will be the case at least with the untrusted applications group) you have to have them both running at the same time. This really gets pretty complex. Do you really think something like this is better than a simple suspend? (I.e. suspend blockers or having just one group) even if all you do is have two groups (trusted and untrusted), all you need to do is to watch for the interaction between these two. Put the third-party apps in the untrusted group. depending on what security you have available, you may be able to define more, smaller groups after using the security to make sure that there is no overlap between them Suppose you implement suspend blockers with a cgroup freeze... how do you implement the freeze/thaw control? I thought the answer had been provided, one of the trusted apps implements the freeze/thaw, and everything happens in userspace. Cheers, Flo p.s.: do you see an possibility for any kind of priority inheritance in the cgroup scheme? I don't. is there a need for it? David Lang -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: [linux-pm] suspend blockers Android integration
2010/6/8 Alan Stern st...@rowland.harvard.edu: On Mon, 7 Jun 2010, Arve Hjønnevåg wrote: The patch that modifies evdev (posted in this patchset) uses an ioctl to enable the suspend blocker. Not all input devices are used for wakeup events and those don't need to block suspend. But you do have a 1-1 correspondence, right? That is, the input devices that are used for wakeup events are exactly the ones that block suspend? Yes. If you read an event that occurred after you blocked the task freezing, then tasks will never get frozen again (until more events occur). I think my original description was less confusing, but it seems you got completely distracted by my use of block and unblock suspend when referring to the user space api. I still find your wording a little confusing. Task freezing can be prevented (a more accurate term than blocked) by two kinds of things: a suspend blocker or an active wakeup source. I'm not sure which kind you mean here. I mean prevented by a user space suspend blocker. It has an indirect connection. You report a wakeup event when it occurs, but clear it when user space calls an api before reading the event. So: Yes, that's right. Wakeup event occurs, and the driver: - report wakeup event type A - queue event for delivery to user-space That's not really two distinct steps. Queuing the event for delivery to userspace involves waking up any tasks that are waiting to read the device file; that action (calling wake_up_all() or whatever the driver does) is how the event gets reported. If you want to ensure that more than one process see the event it has to be two steps, but it does not affect the race I was trying to describe. User space wakes up: - Calls api to block task freezing for event type A Again, that's a confusing way of putting it. The API you're referring to is simply the function that activates a suspend blocker. It does prevent task freezing, but you shouldn't say it prevents freezing for event type A. More like the other way around: In addition to preventing freezing, the function tells the power manager that event type A should no longer be considered active. Thus, in a sense it _stops_ event type A from preventing freezing. Another wakeup event occurs, and the driver: - report wakeup event type A - queue event for delivery to user-space Same as above. User space continues: - Read events Sorry, I missed the unblock task freezing step here. - Wait for more events Result: Task are not frozen again. Because the suspend blocker was never deactivated. The same thing happens with wakelocks: If a task activates a wakelock and never deactivates it, the system won't go into opportunistic suspend again. Yes, but with the sequence of events above task will not be frozen again even if the wake-lock/suspend-blocker/task-freezing-preventer is released. Here's how my scheme is meant to work: Wakeup event for input device A occurs. A's driver adds an entry to the input device queue and (if the queue was empty) does wake_up_all() on the device file's wait_queue. The PM process returns from poll() and sees that device file A is now readable, so it adds A to its list of active sources and unfreezes userspace. Some other process sees that device file A is now readable, so it activates a suspend blocker and reads events from A. When the PM process receives the request to activate the suspend blocker, it removes A from its list of active sources. But it doesn't freeze userspace yet, because now a suspend blocker is active. If another event happens at this point don't you put A back on the list? If so, it never gets removed. The other process consumes events from A and does other stuff. Maybe more input data arrives while this is happening and the process reads it. Eventually the process decides to deactivate the suspend blocker, perhaps when no more data is available from the device file, perhaps not. When the PM process receives the request to deactivate the suspend blocker, it sees that now there are no active sources and no active suspend blockers. Therefore it freezes userspace and does a big poll() on all possible sources. (If there are still events on the input device queue, the poll() returns immediately.) Rinse and repeat. I don't see any dangerous races there. The scheme can be made a little more efficient by having the PM process do another poll() (with 0 timeout) just before freezing userspace; if the result indicates that a source is active then the freezing and unfreezing can be skipped. The big assumption here is that a user process never consumes wakeup events without first activating a suspend blocker. This seems like a reasonable assumption, but we can work around it if
Re: [linux-pm] suspend blockers Android integration
On Tue, 8 Jun 2010, da...@lang.hm wrote: having suspend blockers inside the kernel adds significant complexity, it's worth it only if the complexity buys you enough. In this case the question is if the suspend blockers would extend the sleep time enough more to matter. As per my other e-mail, this is an area with rapidly diminishing returns as the sleep times get longer. Well, the counter-argument that nobody seems to have brought up is that suspend blockers exist, are real code, and end up being shipped in a lot of machines. That's a _big_ argument in favour of them. Certainly much bigger than arguing against them based on some complexity-arguments for an alternative that hasn't seen any testing at all. IOW, I would seriously hope that this discussion was more about real code that _exists_ and does what people need. It seems to have degenerated into something else. Because in the end, code talks, bullshit walks. People can complain and suggest alternatives all they want, but you can't just argue. At some point you need to show the code that actually solves the problem. Linus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Mon, Jun 07, 2010 at 12:26:55AM +0200, Thomas Gleixner wrote: That takes a lot of the bullshit arguments about downstream users being hurt out of the discussion. The above problems are way more complex to resolve than the suspend blocker details. That's another prove why we can let the drivers flow in (in the worst case w/o the suspend blocker stubs) and have no pressure to resolve the suspend blocker problem yesterday. That said, after thinking more about it, I'm advocating the stubs solution with a clear removal / decision date constraint (e.g. 2.6.37), as it forces all involved parties to stay tuned and not to forget about it. I'm curious about the outcome :) As long as we have that clear removal schedule I'm fine with in-kernel suspend blocker stubs. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote: Somebody will have to broker a deal with the frameworks/apps folks to get rid of the binder. They like it a lot. Of course if somebody built a drop-in replacement for the userspace side that didn't require a kernel driver, had the same performance characteristics, solved the same problems, etc, they could probably make an argument for it (or just provide it as a drop-in replacement for people who want a more pure linux underneath Android, even if we didn't pick it up). This wasn't really directed at you, but rather about people talking about running a mainline kernel on Android in this thread. As I said this is a lot more work then sorting out the drivers - with or without suspend blockers. The group ID stuff works incredibly well for gating device access -- we ensure that devices that need access from various processes end up with perms like 0660 root audio (say for a raw audio interface), and then we assure that processes which have the may use audio hardware permission are executed with audio as an additional group. We ended up using the same model to control socket, raw socket, and bt socket access because at the time we could not find a reasonable way to grant or exclude such permissions on a process by process basis. Maintaining about 20-30 lines of diffs to make that work was not a bad tradeoff (and we don't expect those patches to go upstream). If there's a way to accomplish this without patching the kernel, we're all ears. I'd have to take a look again on how this is implemented in details. If it's just overriding the capabilities it's really hard to do in the current model as the capabilities aren't fine grained enough currently, even with the existing per-file and per-process capabilities. If it's mostly overriding regular unix file permissions it's easily doable with ACLs, or in fact just with group ownership at the filesystem level, without kernel hacks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Mon, Jun 7, 2010 at 1:03 AM, Christoph Hellwig h...@infradead.org wrote: On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote: The group ID stuff works incredibly well for gating device access -- we ensure that devices that need access from various processes end up with perms like 0660 root audio (say for a raw audio interface), and then we assure that processes which have the may use audio hardware permission are executed with audio as an additional group. We ended up using the same model to control socket, raw socket, and bt socket access because at the time we could not find a reasonable way to grant or exclude such permissions on a process by process basis. Maintaining about 20-30 lines of diffs to make that work was not a bad tradeoff (and we don't expect those patches to go upstream). If there's a way to accomplish this without patching the kernel, we're all ears. I'd have to take a look again on how this is implemented in details. If it's just overriding the capabilities it's really hard to do in the current model as the capabilities aren't fine grained enough currently, even with the existing per-file and per-process capabilities. If it's mostly overriding regular unix file permissions it's easily doable with ACLs, or in fact just with group ownership at the filesystem level, without kernel hacks. For device nodes, we just use group ownership and it works fine with no kernel modifications. For the can create socket, can create bt socket, and can create raw socket permissions we ended up throwing together a patch tying those operations to being in the appropriate group. Obviously a hack, but it was the most straightforward solution we could find at the time. Brian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/6 Matthew Garrett mj...@srcf.ucam.org: On Sun, Jun 06, 2010 at 07:21:49PM +0200, Vitaly Wool wrote: 2010/6/6 Matthew Garrett mj...@srcf.ucam.org: Suspend blocks prevent system suspend, not any per-device suspend. Can you suspend a device which is holding a wake lock? Yes. Suspend blocks are orthogonal to runtime PM. In that sense yes, but as it has been stated before; if Android user-space concentrates on getting suspend blockers right, then the timers in user-space will not be aligned correctly, and runtime PM wouldn't work that great. Moreover, opportunistic suspend takes the device out of idle. So, as runtime PM gets better, there's a point where opportunistic suspend makes the situation worst. So they are _mostly_ orthogonal, but not completely, at least for the analysis of suspend blockers' usefulness. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, 6 Jun 2010 04:14:09 -0700 (PDT) da...@lang.hm wrote: On Sun, 6 Jun 2010, Florian Mickler wrote: On Sun, 6 Jun 2010 12:19:08 +0200 Vitaly Wool vitalyw...@gmail.com wrote: 2010/6/6 da...@lang.hm: as an example (taken from this thread). system A needs to wake up to get a battery reading, store it and go back to sleep, It does so every 10 seconds. But when it does so it only runs the one process and then goes back to sleep. system B has the same need, but wakes up every 10 minutes. but when it does so it fully wakes up and this allows the mail app to power up the radio, connect to the Internet and start checking for new mail before oppurtunistic sleep shuts things down (causing the mail check to fail) System A will last considerably longer on a battery than System B. Exactly, thanks for pointing out the specific example :) ~Vitaly This does not affect suspend_blockers nor does suspend_blockers interfere with that. Suspend_blockers allow the system to suspend (mem/sys/power/state suspend), when the userspace decides that the device is not in use. So implementing suspend_blockers support does not impact any optimizations done to either system A nor system B. Actually, it does. system A is what's being proposed by kernel developers, where the untrusted stuff is in a different cgroup and what puts the system to sleep is 'normal' power management. It doesn't sleep as long, but when it wakes up the untrusted stuff is still frozen, so it doesn't stay awake long, or do very much. System B is suspend blockers where you are either awake or asleep, and when you wake up you wake up fully, but oppertunistic sleep can interrupt untrusted processes at any time. The system sleeps longer (as fewer things can wake it), but when it wakes up it's fully awake. David Lang You say, that coming back from suspend takes the system to full power (and everything runs) before it begins the descend into runtime-low-power? But are you referring to the fact that coming back from suspend starts in the zero-idle-state (i.e. consumes extra power) or that all processes run when it is not suspended? Because the latter would of course (theretically) profit from the framework-controlled-cgroup-freeze/thaw (with and without opportunistic suspend) while the former should be a problem that both opportunistic suspend as well as suspend-from-idle have. Or not? So, here is the question I'm asking myself: If System A were to be complemented by suspend_blockers, wouldn't it still be better? With System A you could try to do a really sophisticated power-management scheme and so on... but as soon as you allow 3rd-Party Apps, how do you manage their cross-dependencies? I.e. you can not automatically detect when App1 needs App2 to function. You need to allow all 3rd-Party apps to run as a group. So you can perhaps partition your software stack into untrusted applications and different groups of software with audited dependencies. If one group interacts with another group (as will be the case at least with the untrusted applications group) you have to have them both running at the same time. This really gets pretty complex. Do you really think something like this is better than a simple suspend? (I.e. suspend blockers or having just one group) Suppose you implement suspend blockers with a cgroup freeze... how do you implement the freeze/thaw control? Cheers, Flo p.s.: do you see an possibility for any kind of priority inheritance in the cgroup scheme? I don't. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, 6 Jun 2010 19:21:49 +0200 Vitaly Wool vitalyw...@gmail.com wrote: 2010/6/6 Matthew Garrett mj...@srcf.ucam.org: Suspend blocks prevent system suspend, not any per-device suspend. Can you suspend a device which is holding a wake lock? ~Vitaly If you look at the suspend blocker patchset, you'll see that the only patches adding calls to suspend_is_blocked() are PM: Opportunistic suspend support and PM: Abort task freezing if there is an active suspend blocker . Both are in generic suspend code and don't affect runtime pm. Cheers, Flo -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, 2010-06-06 at 12:58 -0700, Brian Swetland wrote: Somebody will have to broker a deal with the frameworks/apps folks to get rid of the binder. They like it a lot. Of course if somebody built a drop-in replacement for the userspace side that didn't require a kernel driver, had the same performance characteristics, solved the same problems, etc, they could probably make an argument for it (or just provide it as a drop-in replacement for people who want a more pure linux underneath Android, even if we didn't pick it up). So what's up with this Binder stuff, from what I can see its just yet-another-CORBA. Why does it need a kernel part at all, can't you simply run with a user-space ORB instead? I really don't get why people keep re-inventing CORBA, there's some really nice (free) ORBs out there, like: http://www.cs.wustl.edu/~schmidt/TAO.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, 6 Jun 2010 20:01:56 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: And since Android can reach essentially the same low-power state from idle as from suspend, it appears that they really don't need any kernel changes at all. Well, perhaps a hint to the scheduler to fall through as fast as possible into deepest idle? Alan Stern Cheers, Flo -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
--- On Mon, 6/7/10, Peter Zijlstra pet...@infradead.org wrote: So what's up with this Binder stuff, from what I can see its just yet-another-CORBA. Why does it need a kernel part at all, can't you simply run with a user-space ORB instead? I really don't get why people keep re-inventing CORBA, That made me laugh. Do you realize that one of the earliest objections to CORBA was why do people keep re-inventing RPC ... :) (Simple answer: the existing stuff didn't solve enough of the right problems ... and it was easier (in a political sense) to come up with something new than to try fixing DCE or ONC (or whatever). Similar answers may still apply ... last I looked at CORBA, it didn't standardize desktop integration (or cell-phone equivalents), and the pure user-space versions suffered slowdowns when looking up object bindings. there's some really nice (free) ORBs out there, -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/7 Peter Zijlstra pet...@infradead.org: On Sun, 2010-06-06 at 12:58 -0700, Brian Swetland wrote: Somebody will have to broker a deal with the frameworks/apps folks to get rid of the binder. They like it a lot. Of course if somebody built a drop-in replacement for the userspace side that didn't require a kernel driver, had the same performance characteristics, solved the same problems, etc, they could probably make an argument for it (or just provide it as a drop-in replacement for people who want a more pure linux underneath Android, even if we didn't pick it up). So what's up with this Binder stuff, from what I can see its just yet-another-CORBA. Why does it need a kernel part at all, can't you simply run with a user-space ORB instead? I really don't get why people keep re-inventing CORBA, there's some really nice (free) ORBs out there, like: http://www.cs.wustl.edu/~schmidt/TAO.html There was a mailthread on LKML a while back where binder was discussed, where Dianne Hackborn explained in detail how Android uses binder. At the time it was contrasted with D-Bus (the IPC mechanism that has largely replaced DCOP (KDE) and Bonobo (GNOME), the latter was actually CORBA-based). I don't think there was any conclusion, but it was pretty clear that binder is an Android key asset, actually the key component that the Android people have brought with them from BeOS to Palmsource to Android to Google, and they really really like to use that thing. It's built into the entire Android userspace for all IPC, except the stuff that's handled by D-Bus instead (yes they have both for some cases). What sets binder aside from the others is that it's kernel-based; things like low-latency and large buffer-passing have been mentioned as key features of the kernel driver. Solving binder one way is to just include it and say it's needed to run Android, the other is to define the technical issue at hand, which is: can the kernel support high-speed, low-latency, partly marshalled, large-buffer IPC? D-Bus (on a local machine, mind you, it can use TCP also) will use a simple unix domain socket by: socket(PF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0) as can be seen here: http://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-sysdeps-unix.c ACE/TAO as referenced seems to use only TCP sockets actually: https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/ACE/ace/Sock_Connect.cpp?view=co Perhaps it simply uses 127.0.0.1 for local IPC. (The source is voluminous and hard for me to navigate, perhaps someone familiar with it can add something here.) Then either D-Bus or TAO builds a complete marshalling stack on top of these sockets, it's all fully abstract, fully userspace. Several processes and dbus daemons push/pull bytes into these sockets. I think DCOP and Bonobo basically do the same thing, by the way. Binder on the other hand is a large kernel module: http://android.git.kernel.org/?p=kernel/experimental.git;a=blob;f=drivers/staging/android/binder.c;h=e13b4c4834076eb64680457049832af0b92d88b9;hb=android-2.6.34-test2 It will do some serious reference counting, handshaking back-and-forth and so on. Basically a lot of the stuff that other IPC mechanisms also does, but in kernelspace. (OK I'm oversimplifying, binder is far more lightweight for one.) The bigger question behind it all is this: Does the kernel provide the proper support for local IPC transport, or is there more it could do in terms of interface, latency, throughput? A domain socket bitsink should be enough for everybody? So I would really like to know from the Android people why the binder is in the kernel, after all. Could it *theoretically* be in userspace, on top of some unix domain sockets, running as a real-time scheduled daemon or whatever, still yielding the same performance? Or is there some discovered limitation with current interfaces, that everybody ought to know? Especially authors of D-Bus and TAO etc would be very interested in this I believe. It's not like I don't understand that it would be hard to move this thing to userspace, it's more that I'd like to know how you think it would be impacted by that. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Mon, Jun 7, 2010 at 4:17 PM, Linus Walleij linus.ml.wall...@gmail.com wrote: So I would really like to know from the Android people why the binder is in the kernel, after all. Could it *theoretically* be in userspace, on top of some unix domain sockets, running as a real-time scheduled daemon or whatever, still yielding the same performance? Or is there some discovered limitation with current interfaces, that everybody ought to know? Especially authors of D-Bus and TAO etc would be very interested in this I believe. It's not like I don't understand that it would be hard to move this thing to userspace, it's more that I'd like to know how you think it would be impacted by that. Fundamentally, yes, you should be able to replicate the functionality in userspace. We considered this during 1.0 development, but it ended up being a lot of risk (at the point when it was discussed) compared to using the existing driver that we had. You almost certainly would need a central daemon to do some state and permission management as well as track some of the refcounting, you could use EPIPE on local sockets to detect remote process termination. You could even just use local sockets for high level control and use shared memory for actual message transport to avoid copy-in-copy-out overhead (another binder driver feature). That said, the userspace environment was built up around the binder, relies on it heavily for all ipc (except for dbus which we use for bluez because it just hasn't been worth the headache to maintain alternate ipc patches for bluez), and is performance sensitive (it's possible that you could achieve similar performance with a suitably clever userspace implementation making use of shared memory, of course), and the frameworks/apps folks are happy with it as is (so talking them into replacing it may be a nontrivial exercise). I wouldn't mind not having to maintain the kernel driver (well, not having Arve have to maintain the kernel driver...) but building a pure-userspace replacement would be a pretty huge undertaking, especially given all the other work we have just with general kernel development, bringup, etc. Since all binder comms in userspace bottlenecks through two small libraries (one C++, one lighter weight C), in theory you could build a drop-in replacement and then prove it out, verify correctness and performance, and make the argument for replacing the existing implementation. Debugging binder implementation issues under a full system using many binder services and patterns like client A calls service B which returns and object in service C, is a bit of a nightmare. I try to stay far away from it, myself. Brian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/6 Alan Stern st...@rowland.harvard.edu: On Sat, 5 Jun 2010, Alan Stern wrote: If you are referring to the approach that we don't use suspend but freeze a cgroup instead, this only solves the problem of bad apps. It does not help pause timers in trusted user space code and in the kernel, so it does not lower our average power consumption. You can solve this problem if you restructure your trusted apps in the right way. Require a trusted app to guarantee that whenever it doesn't hold any suspend blockers, it will do nothing but wait (in a poll() system call for example) for a wakeup event. When the event occurs, it must then activate a suspend blocker. Better yet, make it more fine-grained. Instead of trusted apps, have trusted threads. Freeze the untrusted threads along with everything else, and require the trusted threads to satisfy this guarantee. In this way, while the system is idle no user timers will get renewed. Kernel timers are another matter, but we should be able to handle them. There's nothing Android-specific about wanting to reduce kernel timer wakeups while in a low-power mode. In fact it's possible to do this with only minimal changes to the userspace, providing you can specify all your possible hardware wakeup sources. (On the Android this list probably isn't very large -- I imagine it includes the keypad, the radio link(s), the RTC, and maybe a few switches, buttons, or other things.) Here's how you can do it. Extend the userspace suspend-blocker API, so that each suspend blocker can optionally have an associated wakeup source. The power-manager process should keep a list of active wakeup sources. A source gets removed from the list when an associated suspend blocker is activated. How do you do this safely? If you remove the active wakeup only when activating the suspend blocker, you will never unblock suspend if another wakeup event happens after user-space blocked suspend but before user-space read the events. Also, I'm not sure we can easily associate a wakeup event with a user space suspend blocker. For instance when an alarm triggers it is sometimes because of a user-space alarm and sometimes because an in-kernel alarm. When the active list is empty and no suspend blockers are activated, the power manager freezes ALL other processes, trusted and untrusted alike. It then does a big poll() on all the wakeup sources. When the poll() returns, its output is used to repopulate the active list and processes are unfrozen. (You can also include some error detection: If a source remains on the active list for too long then something has gone wrong.) To do all this you don't even need to use cgroups. The existing PM implementation allows a user process to freeze everything but itself; that's how swsusp and related programs work. This is still a big-hammer sort of approach, but it doesn't require any kernel changes. Alan Stern -- Arve Hjønnevåg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 6, 2010 at 5:01 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sun, 6 Jun 2010, Matthew Garrett wrote: The difference between idle-based suspend and opportunistic suspend is that the former will continue to wake up for timers and will never be entered if something is using CPU, whereas the latter will be entered whenever no suspend blocks are held. The problem with opportunistic suspend is that you might make the decision to suspend simultaneusly with a wakeup event being received. Suspend blocks facilitate synchronisation between the kernel and userspace to ensure that all such events have been consumed and handld appropriately. Remember that suspend takes place in several phases, the first of which is to freeze tasks. The phases can be controlled individually by the process carrying out a suspend, and there's nothing to prevent you from stopping after the freezer phase. Devices won't get powered down, but Android uses aggressive runtime power management for its devices anyway. If you do this then the synchronization can be carried out entirely from userspace, with no need for kernel modifications such as suspend blockers. And since Android can reach essentially the same low-power state from idle as from suspend, it appears that they really don't need any kernel changes at all. I don't think this is true. If you stop after the freezer phase you still need all the suspend blockers that are held until user-space consumes an event, otherwise it never gets consumed since user-space is frozen. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote: In fact it's possible to do this with only minimal changes to the userspace, providing you can specify all your possible hardware wakeup sources. (On the Android this list probably isn't very large -- I imagine it includes the keypad, the radio link(s), the RTC, and maybe a few switches, buttons, or other things.) Here's how you can do it. Extend the userspace suspend-blocker API, so that each suspend blocker can optionally have an associated wakeup source. The power-manager process should keep a list of active wakeup sources. A source gets removed from the list when an associated suspend blocker is activated. How do you do this safely? If you remove the active wakeup only when remove the active wakeup isn't a good way of expressing this. You remove the wakeup source from the power manager's list of active sources. This is just manipulation of a data structure internal to the power manager; it doesn't affect the actual source. activating the suspend blocker, you will never unblock suspend if another wakeup event happens after user-space blocked suspend but before user-space read the events. I'm not sure what you mean. In this scheme userspace doesn't ever block suspends. Instead the power manager freezes and unfreezes all the other processes. And the system never suspends, it simply goes idle for prolonged periods of time... with all processes frozen except the power manager, and it sitting inside a poll() system call. It's true that under some exceptional circumstances the system would never remove a wakeup source from the active list and then would never go idle. But exactly the same problem exists with wakelocks, if the kernel activates a wakelock and there's no user process reading the corresponding event queue. Also, I'm not sure we can easily associate a wakeup event with a user space suspend blocker. For instance when an alarm triggers it is sometimes because of a user-space alarm and sometimes because an in-kernel alarm. That's okay. The association is optional, and not all suspend blockers will have an associated wakeup source. (However, each wakeup source that needs to percolate up into userspace -- i.e., that isn't handled internally by the kernel -- should have at least one associated suspend blocker.) The purpose of these associations is to make explicit the handoff in your original scheme, whereby a source would cause the kernel to activate a wakelock until some user process activated its own and then cleared the kernel's wakelock. In your scheme, the connection between the userspace wakelock and the wakeup source is implicit; in my scheme it is explicit. For example, a process that uses a suspend blocker in order to read keystrokes would obviously associate its suspend blocker with the keypad-matrix wakeup source. Or take your example of an alarm. To make it work in my scheme, each user alarm would have to be implemented as a poll-able file descriptor. Processes reading the descriptor would block until the alarm expires. (I don't know of any driver that provides this sort of timer interface, but it would be easy to write one. You could think of it as applying Unix's Everything is a file philosophy to alarms.) Each of these descriptors would then be a wakeup source, included among the sources that the power manager polls for, and a suspend blocker could be associated with it. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote: Remember that suspend takes place in several phases, the first of which is to freeze tasks. The phases can be controlled individually by the process carrying out a suspend, and there's nothing to prevent you from stopping after the freezer phase. Devices won't get powered down, but Android uses aggressive runtime power management for its devices anyway. If you do this then the synchronization can be carried out entirely from userspace, with no need for kernel modifications such as suspend blockers. And since Android can reach essentially the same low-power state from idle as from suspend, it appears that they really don't need any kernel changes at all. I don't think this is true. If you stop after the freezer phase you still need all the suspend blockers that are held until user-space consumes an event, otherwise it never gets consumed since user-space is frozen. No. You don't need to hold any suspend blockers; you merely need to unfreeze userspace. Once it is unfrozen, it will eventually consume the wakeup event. What you _do_ need to do is to prevent userspace from getting frozen again too soon. That's the purpose of the list of active wakeup sources. So long as the power manager believes a source is still active, it won't freeze anything. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/7 Alan Stern st...@rowland.harvard.edu: On Mon, 7 Jun 2010, Arve Hjønnevåg wrote: In fact it's possible to do this with only minimal changes to the userspace, providing you can specify all your possible hardware wakeup sources. (On the Android this list probably isn't very large -- I imagine it includes the keypad, the radio link(s), the RTC, and maybe a few switches, buttons, or other things.) Here's how you can do it. Extend the userspace suspend-blocker API, so that each suspend blocker can optionally have an associated wakeup source. The power-manager process should keep a list of active wakeup sources. A source gets removed from the list when an associated suspend blocker is activated. How do you do this safely? If you remove the active wakeup only when remove the active wakeup isn't a good way of expressing this. You remove the wakeup source from the power manager's list of active sources. This is just manipulation of a data structure internal to the power manager; it doesn't affect the actual source. activating the suspend blocker, you will never unblock suspend if another wakeup event happens after user-space blocked suspend but before user-space read the events. I'm not sure what you mean. In this scheme userspace doesn't ever block suspends. Instead the power manager freezes and unfreezes all the other processes. And the system never suspends, it simply goes idle for prolonged periods of time... with all processes frozen except the power manager, and it sitting inside a poll() system call. It's true that under some exceptional circumstances the system would never remove a wakeup source from the active list and then would never go idle. But exactly the same problem exists with wakelocks, if the kernel activates a wakelock and there's no user process reading the corresponding event queue. No, you have a different problem. If you open an input device and issue the ioctl to enable the suspend blocker that blocks while the queue is not empty then don't read the event, that is a bug that is easy to fix. What you have is a race condition. If you read an event that occurred after you blocked the task freezing tasks will never get frozen again (until more events occur). Also, I'm not sure we can easily associate a wakeup event with a user space suspend blocker. For instance when an alarm triggers it is sometimes because of a user-space alarm and sometimes because an in-kernel alarm. That's okay. The association is optional, and not all suspend blockers will have an associated wakeup source. (However, each wakeup source that needs to percolate up into userspace -- i.e., that isn't handled internally by the kernel -- should have at least one associated suspend blocker.) The purpose of these associations is to make explicit the handoff in your original scheme, whereby a source would cause the kernel to activate a wakelock until some user process activated its own and then cleared the kernel's wakelock. In your scheme, the connection between the userspace wakelock and the wakeup source is implicit; in my scheme it is explicit. For example, a process that uses a suspend blocker in order to read keystrokes would obviously associate its suspend blocker with the keypad-matrix wakeup source. We have multiple input devices and one thread reading from them. Do all input devices that can generate wakeup events share a wakeup source? Or take your example of an alarm. To make it work in my scheme, each user alarm would have to be implemented as a poll-able file descriptor. Processes reading the descriptor would block until the alarm expires. (I don't know of any driver that provides this sort of timer interface, but it would be easy to write one. You could think of it as applying Unix's Everything is a file philosophy to alarms.) Each of these descriptors would then be a wakeup source, included among the sources that the power manager polls for, and a suspend blocker could be associated with it. It seems you would need a way to pass the wakeup source id to use from user space to the driver and for this to work (ignoring the race if you allow multiple alarms per file) which seems like more work than using a suspend blocker. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Tue, 08 Jun 2010 01:17:13 +0200, Linus Walleij said: So I would really like to know from the Android people why the binder is in the kernel, after all. Could it *theoretically* be in userspace, on top of some unix domain sockets, running as a real-time scheduled daemon or whatever, still yielding the same performance? Or is there some discovered limitation with current interfaces, that everybody ought to know? Not an Android person, but... How expensive is a userspace-kernel transition on Android-class hardware? There's certainly something to be said for short-circuiting the path source_process - kernel - broker_process - kernel - dest_process down to the shorter source-kernel-dest pgpWR2QCzXuiD.pgp Description: PGP signature
Re: [linux-pm] suspend blockers Android integration
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote: It's true that under some exceptional circumstances the system would never remove a wakeup source from the active list and then would never go idle. But exactly the same problem exists with wakelocks, if the kernel activates a wakelock and there's no user process reading the corresponding event queue. No, you have a different problem. If you open an input device and issue the ioctl to enable the suspend blocker that blocks while the Um, the suspend blocker that is active while the queue is nonempty is an in-kernel suspend blocker, right? Not a userspace suspend blocker. Hence it doesn't have to be enabled by an ioctl. Or is this some part of the whole wakelock design that hasn't yet been posted? As far as I know, you intended the in-kernel suspend blocker to be enabled whenever the input device file is open. queue is not empty then don't read the event, that is a bug that is easy to fix. I assume you mean you open an input device but then fail to read from it. When that happens the device's driver will activate its in-kernel suspend blocker, and since the input queue will never become empty, the suspend blocker will never be deactivated. Yes, that's a bug. What you have is a race condition. If you read an event that occurred after you blocked the task freezing tasks will never get frozen again (until more events occur). Sorry, I can't parse that sentence. Could you rephrase it more grammatically? It seems to say: If you read an event that occurred after [something], then tasks won't get frozen again until more events occur. Which doesn't make sense, firstly because in my scheme reading events has no direct connection with freezing or unfreezing tasks, and secondly because the occurrence of events doesn't cause tasks to be frozen -- just the opposite: occurrence of events _prevents_ tasks from being frozen. We have multiple input devices and one thread reading from them. Do all input devices that can generate wakeup events share a wakeup source? Basically, a wakeup source is a file descriptor that in your scheme, some user process would read from in order to clear an in-kernel wakelock. Thus, if each of your input devices activates an in-kernel wakelock that is cleared when a user process reads the device, then the file descriptors for these input devices would each be considered a wakeup source. It seems you would need a way to pass the wakeup source id to use from user space to the driver and for this to work No, nothing needs to be passed from userspace to the kernel. However the source ID (or a set of source IDs) does need to be passed to the power manager process, probably when the suspend blocker is created. [On rereading this, I realized it might not have been clear that in my scheme, suspend blockers have no in-kernel component. They are implemented entirely by IPC between the process owning the suspend blocker and the power manager process. Would it be less confusing if I called them something else?] (ignoring the race if you allow multiple alarms per file) which seems like more work than using a suspend blocker. It's not very much more: just one additional argument to the routine that creates a suspend blocker. I get the impression that you don't fully understand how my scheme is meant to work. Would some additional explanation or examples help? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/7 Alan Stern st...@rowland.harvard.edu: On Mon, 7 Jun 2010, Arve Hjønnevåg wrote: It's true that under some exceptional circumstances the system would never remove a wakeup source from the active list and then would never go idle. But exactly the same problem exists with wakelocks, if the kernel activates a wakelock and there's no user process reading the corresponding event queue. No, you have a different problem. If you open an input device and issue the ioctl to enable the suspend blocker that blocks while the Um, the suspend blocker that is active while the queue is nonempty is an in-kernel suspend blocker, right? Not a userspace suspend blocker. Hence it doesn't have to be enabled by an ioctl. Or is this some part of the whole wakelock design that hasn't yet been posted? As far as I know, you intended the in-kernel suspend blocker to be enabled whenever the input device file is open. The patch that modifies evdev (posted in this patchset) uses an ioctl to enable the suspend blocker. Not all input devices are used for wakeup events and those don't need to block suspend. queue is not empty then don't read the event, that is a bug that is easy to fix. I assume you mean you open an input device but then fail to read from it. When that happens the device's driver will activate its in-kernel suspend blocker, and since the input queue will never become empty, the suspend blocker will never be deactivated. Yes, that's a bug. What you have is a race condition. If you read an event that occurred after you blocked the task freezing tasks will never get frozen again (until more events occur). Sorry, I can't parse that sentence. Could you rephrase it more grammatically? If you read an event that occurred after you blocked the task freezing, then tasks will never get frozen again (until more events occur). I think my original description was less confusing, but it seems you got completely distracted by my use of block and unblock suspend when referring to the user space api. It seems to say: If you read an event that occurred after [something], Block suspend, block task freezing or whatever you want to call it. then tasks won't get frozen again until more events occur. Which doesn't make sense, firstly because in my scheme reading events has no direct connection with freezing or unfreezing tasks, and secondly It has an indirect connection. You report a wakeup event when it occurs, but clear it when user space calls an api before reading the event. So: Wakeup event occurs, and the driver: - report wakeup event type A - queue event for delivery to user-space User space wakes up: - Calls api to block task freezing for event type A Another wakeup event occurs, and the driver: - report wakeup event type A - queue event for delivery to user-space User space continues: - Read events - Wait for more events Result: Task are not frozen again. because the occurrence of events doesn't cause tasks to be frozen -- just the opposite: occurrence of events _prevents_ tasks from being frozen. We have multiple input devices and one thread reading from them. Do all input devices that can generate wakeup events share a wakeup source? Basically, a wakeup source is a file descriptor that in your scheme, some user process would read from in order to clear an in-kernel wakelock. Thus, if each of your input devices activates an in-kernel wakelock that is cleared when a user process reads the device, then the file descriptors for these input devices would each be considered a wakeup source. It seems you would need a way to pass the wakeup source id to use from user space to the driver and for this to work No, nothing needs to be passed from userspace to the kernel. However the source ID (or a set of source IDs) does need to be passed to the power manager process, probably when the suspend blocker is created. Then the source id need to be passed from the kernel to user-space. [On rereading this, I realized it might not have been clear that in my scheme, suspend blockers have no in-kernel component. They are implemented entirely by IPC between the process owning the suspend blocker and the power manager process. Would it be less confusing if I called them something else?] No, that is not the unclear part. What is unclear to me is where the source IDs come from. Are they static and hardcoded in the driver and user-space, or are they passed between the driver and user-space client? (ignoring the race if you allow multiple alarms per file) which seems like more work than using a suspend blocker. It's not very much more: just one additional argument to the routine that creates a suspend blocker. I get the impression that you don't fully understand how my scheme is meant to work. Would some additional explanation or examples help? I don't understand how you are planning to ensure that the driver and user-space code that consumes the
Re: [linux-pm] suspend blockers Android integration
2010/6/5 Arve Hjønnevåg a...@android.com: On Sat, Jun 5, 2010 at 9:28 AM, Arjan van de Ven ar...@infradead.org wrote: On Sat, 05 Jun 2010 11:54:13 +0200 Peter Zijlstra pet...@infradead.org wrote: On Fri, 2010-06-04 at 17:10 -0700, Arve Hjønnevåg wrote: Trusted processes are assumed to be sane and idle when there is nothing for them to do, allowing the machine to go into deep idle states. Neither the kernel nor our trusted user-space code currently meets this criteria. Then both need fixing. Really, that's the only sane approach. fwiw... in MeeGo we're seeing quite good idle times ( 1 seconds) without really bad hacks. We clearly have different standards for what we consider good. We measure time suspended in minutes or hours, not seconds, and waking up every second or two causes a noticeable decrease in battery life on the hardware we have today. Are you stating that the existing Android implementation enters the suspended state for hours for any of the existing designs? ~Vitaly -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 6, 2010 at 12:52 AM, Vitaly Wool vitalyw...@gmail.com wrote: 2010/6/5 Arve Hjønnevåg a...@android.com: We clearly have different standards for what we consider good. We measure time suspended in minutes or hours, not seconds, and waking up every second or two causes a noticeable decrease in battery life on the hardware we have today. Are you stating that the existing Android implementation enters the suspended state for hours for any of the existing designs? It varies depending on device and usage. The battery monitoring on NexusOne happens every ten minutes, so that's the longest you'll see a N1 suspended for. On a G1 or Dream/myTouch you can see 20-30 minutes between wakeups (depending on network issues and background data sync traffic), and if you have background data sync off those devices can sit in suspend for days at a time (unless you receive a phone call or something). In airplane mode, with no local alarms, a device can easily sit in the lowest power state for a month or so, until the battery finally runs out. Brian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 6, 2010 at 10:20 AM, Brian Swetland swetl...@google.com wrote: On Sun, Jun 6, 2010 at 12:52 AM, Vitaly Wool vitalyw...@gmail.com wrote: 2010/6/5 Arve Hjønnevåg a...@android.com: We clearly have different standards for what we consider good. We measure time suspended in minutes or hours, not seconds, and waking up every second or two causes a noticeable decrease in battery life on the hardware we have today. Are you stating that the existing Android implementation enters the suspended state for hours for any of the existing designs? It varies depending on device and usage. The battery monitoring on NexusOne happens every ten minutes, so that's the longest you'll see a N1 suspended for. On a G1 or Dream/myTouch you can see 20-30 minutes between wakeups (depending on network issues and background data sync traffic), and if you have background data sync off those devices can sit in suspend for days at a time (unless you receive a phone call or something). In airplane mode, with no local alarms, a device can easily sit in the lowest power state for a month or so, until the battery finally runs out. That only concerns the case when you have just turned on the phone and left it laying around. You have to admit that it's not the common case for a smartphone. The common case is that you've played with it for a bit, turning on things like BT/WIFI, running some apps and so on. And doing so you'll end up having wake locks taken from everywhere, so I can hardly see a second of suspend for Nexus. E. g. when the wireless is connected to an AP, it takes a wake lock which is released on 15 minutes touchscreen inactivity timeout, as far as I can tell. So: * the system will never hit suspend during this period; * if the download was ongoing and had not been completed during this period, it will be terminated. So the bottom line is: the approach is very inflexible. Of course it can give you the best power savings if you turn the Airplane mode on as soon as you switched on the phone, but this is not what a typical user would do. ~Vitaly -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 6, 2010 at 1:32 AM, Vitaly Wool vitalyw...@gmail.com wrote: It varies depending on device and usage. The battery monitoring on NexusOne happens every ten minutes, so that's the longest you'll see a N1 suspended for. On a G1 or Dream/myTouch you can see 20-30 minutes between wakeups (depending on network issues and background data sync traffic), and if you have background data sync off those devices can sit in suspend for days at a time (unless you receive a phone call or something). In airplane mode, with no local alarms, a device can easily sit in the lowest power state for a month or so, until the battery finally runs out. That only concerns the case when you have just turned on the phone and left it laying around. You have to admit that it's not the common case for a smartphone. The common case is that you've played with it for a bit, turning on things like BT/WIFI, running some apps and so on. And doing so you'll end up having wake locks taken from everywhere, so I can hardly see a second of suspend for Nexus. The common case for a phone is to be sitting around. Even for heavy smartphone users, unless they power on, use the device screen-on for 4 hours solid or whatnot and drain the battery straight away, the device is going to spend a significant portion of its operating time in screen-off standby modes (conserving power for when you take a call, browse the web, etc). For typical users on typical android devices, this means the device stays suspended for 5-10 minutes at a time, coming up for air when a network packet (mail sync, im, etc) or alarm (battery monitor) wakes the device briefly. Obviously with the right combination of bad apps you will see a device suspending more rarely. E. g. when the wireless is connected to an AP, it takes a wake lock which is released on 15 minutes touchscreen inactivity timeout, as far as I can tell. So: * the system will never hit suspend during this period; * if the download was ongoing and had not been completed during this period, it will be terminated. I'm pretty sure the wifi subsystem does not actually take a wakelock while its connected -- it does have an alarm to spin down wifi after 15 minutes (by default, and user disableable) largely due to power inefficiencies in the wifi solution in some early devices. There's some room for improvement here, obviously. With a decent wifi chipset and implementation, depending on local wifi traffic patterns, you can see power usage competitive to cellular. So the bottom line is: the approach is very inflexible. Of course it can give you the best power savings if you turn the Airplane mode on as soon as you switched on the phone, but this is not what a typical user would do. The savings in airplane mode (apart from preventing data connections, which saves power by preventing data-hungry background apps from doing much) is the difference between standby with radio (3-5mA) and without (1-2mA). I'm not suggesting that airplane mode is a typical case, just using it as in illustration of the more extreme standby case. Users do like that to work too -- I recall Arve leaving a device in his filing cabinet with the radio off while he was out of the country for three weeks once, and him discovering it was still running with something like 25% battery remaining when he returned. In any case, I'm saying that suspending for minutes at a time (typical, 10s of minutes or more in some cases, hours in others), does happen and it does represent an improvement over suspending or otherwise entering your lowest power state for seconds at a time. Brian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, 6 Jun 2010, Brian Swetland wrote: The savings in airplane mode (apart from preventing data connections, which saves power by preventing data-hungry background apps from doing much) is the difference between standby with radio (3-5mA) and without (1-2mA). I'm not suggesting that airplane mode is a typical case, just using it as in illustration of the more extreme standby case. for the sake of discussion, let's say that standby is 5ma and full operation is 500ma and a minimal wakeup is 0.1 sec. these are probably fairly pessimistic numbers. waking up every second would be awake 10% of the time, so in an hour you would use .9*5mA + .1*500mA = 4.5mA +45mA = 49.5mAH waking up every 10 seconds would be awake 1% of the time, so in an hour you would use .99*5mA + 0.01*500mA = 4.95mA + 5mA = 9.95mAH waking up every 100 seconds would be awake 0.1% of the time, so in an hour you would use .999*5mA + 0.001*500mA =4.995mA + 0.5mA = 5.495mAH waking up every 1000 seconds would be awake 0.01% of the time so in an hour you would use .*5mA + 0.0001*500mA = 4.9995mA + 0.05mAH = 5.0495mAH now if you have a 1000mAH battery (small, but reasonable for a smartphone) your standby life would be .1 second wakeup (on continuously) = 2 hours 1 second wakup = 20 hours 10 second wakeup = 100 hours 100 second wakeup = 182 hours 1000 second wakeup = 198 hours if you could shrink the time awake to 0.01 second per wakeup you would shift this all up a category (and avoiding the need to wake everything up to service a timer would help do this) this effort very definantly has diminishing returns as you go to larger sleep periods as the constant standby power draw becomes more and more dominating. someone mentioned that they were getting the sleep time of normal systems up past the 1 second mark with the 10 second mark looking very attainable. that is where you get the most benifit for whatever changes are needed. getting up to a 2 min sleep time really gives you about all the benifit that you can get, going from there to 15 min makes very little difference. don't let chasing the best possible sleep time prevent you from considering options that would be good enough in time, but would drastically reduce the maintinance effort (as things could be upstreamed more easily), and would be usable on far more systems. David Lang -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 6, 2010 at 11:21 AM, Brian Swetland swetl...@google.com wrote: The common case for a phone is to be sitting around. Even for heavy smartphone users, unless they power on, use the device screen-on for 4 hours solid or whatnot and drain the battery straight away, the device is going to spend a significant portion of its operating time in screen-off standby modes (conserving power for when you take a call, browse the web, etc). Sure, but my point was, some non-trivial (still kind of natural for a smartphone) activities with the device will prevent it from suspending for quite some time. Even worse, the suspend wakelock will keep the whole kernel active, as opposed to powering off unused devices separately as it's done in runtime PM. Yep, I know about the early suspend type of thing; yet it's excess, not mainlined and lacks granularity. For typical users on typical android devices, this means the device stays suspended for 5-10 minutes at a time, coming up for air when a network packet (mail sync, im, etc) or alarm (battery monitor) wakes the device briefly. Obviously with the right combination of bad apps you will see a device suspending more rarely. Wasn't that you who stated that you so successfully tolerate bad apps with opportunistic suspend that anything of the kind should not really be the case? :) E. g. when the wireless is connected to an AP, it takes a wake lock which is released on 15 minutes touchscreen inactivity timeout, as far as I can tell. So: * the system will never hit suspend during this period; * if the download was ongoing and had not been completed during this period, it will be terminated. I'm pretty sure the wifi subsystem does not actually take a wakelock while its connected -- it does have an alarm to spin down wifi after 15 minutes (by default, and user disableable) largely due to power inefficiencies in the wifi solution in some early devices. Oh? How does it make sure it's not powered off while scanning for APs, for instance? Users do like that to work too -- I recall Arve leaving a device in his filing cabinet with the radio off while he was out of the country for three weeks once, and him discovering it was still running with something like 25% battery remaining when he returned. So what you're actually up to is that a user should restart the phone and turn the radio off if he wants to find it running when he's back from a long business trip or something. Nice... In any case, I'm saying that suspending for minutes at a time (typical, 10s of minutes or more in some cases, hours in others), does happen and it does represent an improvement over suspending or otherwise entering your lowest power state for seconds at a time. That's for sure, if _all_ the other parameters *are* *equal*. This is obviously not the case. ~Vitaly -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, 6 Jun 2010, Vitaly Wool wrote: On Sun, Jun 6, 2010 at 11:21 AM, Brian Swetland swetl...@google.com wrote: In any case, I'm saying that suspending for minutes at a time (typical, 10s of minutes or more in some cases, hours in others), does happen and it does represent an improvement over suspending or otherwise entering your lowest power state for seconds at a time. That's for sure, if _all_ the other parameters *are* *equal*. This is obviously not the case. and while it will represent an improvement, is the cost worth the relativly minor benifit that going from 10s of seconds of sleep to 10s of minuites of sleep give you? a system that wakes up every 10 seconds, but only wakes the portion of the system needed for the wakeup can easily outlast one that wakes up far less frequently, but when it's awake is fully awake. as an example (taken from this thread). system A needs to wake up to get a battery reading, store it and go back to sleep, It does so every 10 seconds. But when it does so it only runs the one process and then goes back to sleep. system B has the same need, but wakes up every 10 minutes. but when it does so it fully wakes up and this allows the mail app to power up the radio, connect to the Internet and start checking for new mail before oppurtunistic sleep shuts things down (causing the mail check to fail) System A will last considerably longer on a battery than System B. David Lang -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/6 da...@lang.hm: as an example (taken from this thread). system A needs to wake up to get a battery reading, store it and go back to sleep, It does so every 10 seconds. But when it does so it only runs the one process and then goes back to sleep. system B has the same need, but wakes up every 10 minutes. but when it does so it fully wakes up and this allows the mail app to power up the radio, connect to the Internet and start checking for new mail before oppurtunistic sleep shuts things down (causing the mail check to fail) System A will last considerably longer on a battery than System B. Exactly, thanks for pointing out the specific example :) ~Vitaly -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, 6 Jun 2010 12:00:47 +0200 Vitaly Wool vitalyw...@gmail.com wrote: Even worse, the suspend wakelock will keep the whole kernel active, as opposed to powering off unused devices separately as it's done in runtime PM. That is not true. While the kernel is not suspended it does runtime pm. Users do like that to work too -- I recall Arve leaving a device in his filing cabinet with the radio off while he was out of the country for three weeks once, and him discovering it was still running with something like 25% battery remaining when he returned. So what you're actually up to is that a user should restart the phone and turn the radio off if he wants to find it running when he's back from a long business trip or something. Nice... ? Cheers, Flo -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, 6 Jun 2010 12:19:08 +0200 Vitaly Wool vitalyw...@gmail.com wrote: 2010/6/6 da...@lang.hm: as an example (taken from this thread). system A needs to wake up to get a battery reading, store it and go back to sleep, It does so every 10 seconds. But when it does so it only runs the one process and then goes back to sleep. system B has the same need, but wakes up every 10 minutes. but when it does so it fully wakes up and this allows the mail app to power up the radio, connect to the Internet and start checking for new mail before oppurtunistic sleep shuts things down (causing the mail check to fail) System A will last considerably longer on a battery than System B. Exactly, thanks for pointing out the specific example :) ~Vitaly This does not affect suspend_blockers nor does suspend_blockers interfere with that. Suspend_blockers allow the system to suspend (mem/sys/power/state suspend), when the userspace decides that the device is not in use. So implementing suspend_blockers support does not impact any optimizations done to either system A nor system B. Cheers, Flo -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, 6 Jun 2010 12:46:01 +0200 Florian Mickler flor...@mickler.org wrote: On Sun, 6 Jun 2010 12:00:47 +0200 Vitaly Wool vitalyw...@gmail.com wrote: Even worse, the suspend wakelock will keep the whole kernel active, as opposed to powering off unused devices separately as it's done in runtime PM. That is not true. While the kernel is not suspended it does runtime pm. On several of our platforms runtime PM already includes suspend so a suspend wakelock does interfere with existing power managemet at that level (not to mention the maintenance mess it causes). This is one of the reasons you want QoS information, it provides parameters by which the power management code can make a decision. Suspend blocksers simply don't have sufficient variety to manage the direction of power policy. If Android chooses to abuse the QoS information for crude suspend blocking then that is fine, it doesn't interfere with doing the job 'properly' on other systems or its use for realtime work on other boxes. Alan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/6 Florian Mickler flor...@mickler.org: Suspend_blockers allow the system to suspend (mem/sys/power/state suspend), when the userspace decides that the device is not in use. Sorry. What? Blockers allow the system to suspend? So implementing suspend_blockers support does not impact any optimizations done to either system A nor system B. Suspend blockers by themselves are of no use. Completely. So any talks on suspend blockers separated from the sleep policy are completely pointless. The suspend blockers are of use when the userspace tries to blindly freeze the tasks to enter the suspend state. This way of hammering the system down obviously impacts everything. ~Vitaly -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sat, 5 Jun 2010, Alan Stern wrote: If you are referring to the approach that we don't use suspend but freeze a cgroup instead, this only solves the problem of bad apps. It does not help pause timers in trusted user space code and in the kernel, so it does not lower our average power consumption. You can solve this problem if you restructure your trusted apps in the right way. Require a trusted app to guarantee that whenever it doesn't hold any suspend blockers, it will do nothing but wait (in a poll() system call for example) for a wakeup event. When the event occurs, it must then activate a suspend blocker. Better yet, make it more fine-grained. Instead of trusted apps, have trusted threads. Freeze the untrusted threads along with everything else, and require the trusted threads to satisfy this guarantee. In this way, while the system is idle no user timers will get renewed. Kernel timers are another matter, but we should be able to handle them. There's nothing Android-specific about wanting to reduce kernel timer wakeups while in a low-power mode. In fact it's possible to do this with only minimal changes to the userspace, providing you can specify all your possible hardware wakeup sources. (On the Android this list probably isn't very large -- I imagine it includes the keypad, the radio link(s), the RTC, and maybe a few switches, buttons, or other things.) Here's how you can do it. Extend the userspace suspend-blocker API, so that each suspend blocker can optionally have an associated wakeup source. The power-manager process should keep a list of active wakeup sources. A source gets removed from the list when an associated suspend blocker is activated. When the active list is empty and no suspend blockers are activated, the power manager freezes ALL other processes, trusted and untrusted alike. It then does a big poll() on all the wakeup sources. When the poll() returns, its output is used to repopulate the active list and processes are unfrozen. (You can also include some error detection: If a source remains on the active list for too long then something has gone wrong.) To do all this you don't even need to use cgroups. The existing PM implementation allows a user process to freeze everything but itself; that's how swsusp and related programs work. This is still a big-hammer sort of approach, but it doesn't require any kernel changes. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/6 da...@lang.hm: On Sun, 6 Jun 2010, Brian Swetland wrote: if you could shrink the time awake to 0.01 second per wakeup you would shift this all up a category (and avoiding the need to wake everything up to service a timer would help do this) this effort very definantly has diminishing returns as you go to larger sleep periods as the constant standby power draw becomes more and more dominating. someone mentioned that they were getting the sleep time of normal systems up past the 1 second mark with the 10 second mark looking very attainable. that is where you get the most benifit for whatever changes are needed. getting up to a 2 min sleep time really gives you about all the benifit that you can get, going from there to 15 min makes very little difference. don't let chasing the best possible sleep time prevent you from considering options that would be good enough in time, but would drastically reduce the maintinance effort (as things could be upstreamed more easily), and would be usable on far more systems. Not to mention the fact that there's nothing fundamental that prevents dynamic PM to reach 15 min idle. It's a matter of time before we find the tools needed. The amount of work that suspend blockers would require to implement properly in user-space other than Android just doesn't match the power savings. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, 6 Jun 2010, Florian Mickler wrote: On Sun, 6 Jun 2010 12:19:08 +0200 Vitaly Wool vitalyw...@gmail.com wrote: 2010/6/6 da...@lang.hm: as an example (taken from this thread). system A needs to wake up to get a battery reading, store it and go back to sleep, It does so every 10 seconds. But when it does so it only runs the one process and then goes back to sleep. system B has the same need, but wakes up every 10 minutes. but when it does so it fully wakes up and this allows the mail app to power up the radio, connect to the Internet and start checking for new mail before oppurtunistic sleep shuts things down (causing the mail check to fail) System A will last considerably longer on a battery than System B. Exactly, thanks for pointing out the specific example :) ~Vitaly This does not affect suspend_blockers nor does suspend_blockers interfere with that. Suspend_blockers allow the system to suspend (mem/sys/power/state suspend), when the userspace decides that the device is not in use. So implementing suspend_blockers support does not impact any optimizations done to either system A nor system B. Actually, it does. system A is what's being proposed by kernel developers, where the untrusted stuff is in a different cgroup and what puts the system to sleep is 'normal' power management. It doesn't sleep as long, but when it wakes up the untrusted stuff is still frozen, so it doesn't stay awake long, or do very much. System B is suspend blockers where you are either awake or asleep, and when you wake up you wake up fully, but oppertunistic sleep can interrupt untrusted processes at any time. The system sleeps longer (as fewer things can wake it), but when it wakes up it's fully awake. David Lang -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 06, 2010 at 12:00:47PM +0200, Vitaly Wool wrote: Sure, but my point was, some non-trivial (still kind of natural for a smartphone) activities with the device will prevent it from suspending for quite some time. Even worse, the suspend wakelock will keep the whole kernel active, as opposed to powering off unused devices separately as it's done in runtime PM. Yep, I know about the early suspend type of thing; yet it's excess, not mainlined and lacks granularity. Holding a suspend blocker is entirely orthogonal to runtime pm. The whole kernel will not be active - it can continue to hit the same low power state in the idle loop, and any runtime pm implementation in the drivers will continue to be active. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 06, 2010 at 12:05:57PM +0100, Alan Cox wrote: On Sun, 6 Jun 2010 12:46:01 +0200 Florian Mickler flor...@mickler.org wrote: That is not true. While the kernel is not suspended it does runtime pm. On several of our platforms runtime PM already includes suspend so a suspend wakelock does interfere with existing power managemet at that level (not to mention the maintenance mess it causes). No, it doesn't. Android on omap will enter the mpu/core off state from the idle loop even if a suspend block is held. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, 2010-06-06 at 12:05 +0100, Alan Cox wrote: On Sun, 6 Jun 2010 12:46:01 +0200 Florian Mickler flor...@mickler.org wrote: On Sun, 6 Jun 2010 12:00:47 +0200 Vitaly Wool vitalyw...@gmail.com wrote: Even worse, the suspend wakelock will keep the whole kernel active, as opposed to powering off unused devices separately as it's done in runtime PM. That is not true. While the kernel is not suspended it does runtime pm. On several of our platforms runtime PM already includes suspend so a suspend wakelock does interfere with existing power managemet at that level (not to mention the maintenance mess it causes). This is one of the reasons you want QoS information, it provides parameters by which the power management code can make a decision. Suspend blocksers simply don't have sufficient variety to manage the direction of power policy. If Android chooses to abuse the QoS information for crude suspend blocking then that is fine, it doesn't interfere with doing the job 'properly' on other systems or its use for realtime work on other boxes. Right ... and I think we can make use of this as an incremental way forwards. This QoS re-expression needs doing for the suspend from idle + cgroup approach, and it can be made to work with the current suspend blockers patch. I've already posted most of the necessary improvements to pm_qos, all of which end up looking like the right thing to do independent of android. There's really only one remaining thing, and that's adding statistics. Once stats are added, I think I can transform the 8 android patches into a set of 7 pm_qos transformations and one patch that adds the opportunistic suspend infrastructure. The 7 pm_qos patches should be reasonably uncontroversial, but what they would allow us to do is to unblock about 75% of the driver divergences from Qualcomm and others. The 1 opportunistic suspend one will be confined to one or two files, so is easy to maintain ... we can then argue over who should maintain it in the interim, us or Google. From this basis, we can then proceed to look at implementing the cgroups + suspend from idle approach, and we can do this regardless of whether the opportunistic suspend patch is applied or not. There are three reasons why the whole debate is going in circles 1. Lots of people are taking a holistic approach (i.e. must solve everything) ... this means that previously unarticulated issues keep cropping up that are unrelated to the current patch set ... but which set off another cascade of emails. 2. There currently is no cgroups + suspend from idle approach implemented anywhere. That means we have to argue theoreticals rather than actuals (theoreticals are easy to shoot down with other theoretical arguments ... leading to another email cascade). If we implemented the thing, these arguments would compare one factual basis to another. 3. We've lost sight of one of the original goals, which was to bring the android tree close enough to the kernel so that the android downstream driver and board producers don't have to choose between the android kernel and vanilla kernel. I think the proposal above gets us to within 75% of the way to 3, moves us towards a factual basis for 2 and eliminates some of the grounds for argument of 1 ... now can we please get on with it? James -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/6 Matthew Garrett mj...@srcf.ucam.org: On Sun, Jun 06, 2010 at 12:00:47PM +0200, Vitaly Wool wrote: Sure, but my point was, some non-trivial (still kind of natural for a smartphone) activities with the device will prevent it from suspending for quite some time. Even worse, the suspend wakelock will keep the whole kernel active, as opposed to powering off unused devices separately as it's done in runtime PM. Yep, I know about the early suspend type of thing; yet it's excess, not mainlined and lacks granularity. Holding a suspend blocker is entirely orthogonal to runtime pm. The whole kernel will not be active - it can continue to hit the same low power state in the idle loop, and any runtime pm implementation in the drivers will continue to be active. Yeah, that might also be the case, But then again, what's the use of suspend blockers in this situation? ~Vitaly -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 06, 2010 at 05:26:09PM +0200, Vitaly Wool wrote: 2010/6/6 Matthew Garrett mj...@srcf.ucam.org: Holding a suspend blocker is entirely orthogonal to runtime pm. The whole kernel will not be active - it can continue to hit the same low power state in the idle loop, and any runtime pm implementation in the drivers will continue to be active. Yeah, that might also be the case, But then again, what's the use of suspend blockers in this situation? The difference between idle-based suspend and opportunistic suspend is that the former will continue to wake up for timers and will never be entered if something is using CPU, whereas the latter will be entered whenever no suspend blocks are held. The problem with opportunistic suspend is that you might make the decision to suspend simultaneusly with a wakeup event being received. Suspend blocks facilitate synchronisation between the kernel and userspace to ensure that all such events have been consumed and handld appropriately. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, 6 Jun 2010, James Bottomley wrote: 3. We've lost sight of one of the original goals, which was to bring the android tree close enough to the kernel so that the android downstream driver and board producers don't have to choose between the android kernel and vanilla kernel. There are two ways to do that w/o creating a dependcy on anything. 1) merge the drivers w/o the suspend_blockers. It's not rocket science to have a patch which brings them back for android. 2) merge the drivers with empty stub implementations for annotation. android just has to patch in the real one. While I'd prefer #1, I' not in the way of #2. Both ways can get the drivers into the kernel and it could/should have been done right from the beginning, but now we face a situation where drivers are held hostage. Then we can sit down more relaxed and fix the stuff in a way which makes both sides happy. If we manage to replace them, we can deprecate the stub implementation and remove it after a grace period. If we rename them it's not an issue either. We can rename them right away to a qos interface, but that does not really make a difference. What we really want to avoid is implementing an user space contract in a frenzy which binds us forever. It's not the suspend_blockers which are the causing the nightmare, it's solely the drivers itself especially when there are different implementations in both trees. And frankly, the drivers in android are not in a shape which makes them flood in within 2 weeks. That's serious work to get them brushed up and polished. So that gives us quite a period of time to solve the suspend problem. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/6 Matthew Garrett mj...@srcf.ucam.org: On Sun, Jun 06, 2010 at 05:26:09PM +0200, Vitaly Wool wrote: 2010/6/6 Matthew Garrett mj...@srcf.ucam.org: Holding a suspend blocker is entirely orthogonal to runtime pm. The whole kernel will not be active - it can continue to hit the same low power state in the idle loop, and any runtime pm implementation in the drivers will continue to be active. Yeah, that might also be the case, But then again, what's the use of suspend blockers in this situation? The difference between idle-based suspend and opportunistic suspend is that the former will continue to wake up for timers and will never be entered if something is using CPU, whereas the latter will be entered whenever no suspend blocks are held. The problem with opportunistic suspend is that you might make the decision to suspend simultaneusly with a wakeup event being received. Suspend blocks facilitate synchronisation between the kernel and userspace to ensure that all such events have been consumed and handld appropriately. Right, and then you start taking suspend blockers in kernel here and there which eventually interferes with runtime PM. So I don't buy the orthogonality point. Generally speaking, it's not true. ~Vitaly -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 06, 2010 at 05:47:10PM +0200, Vitaly Wool wrote: 2010/6/6 Matthew Garrett mj...@srcf.ucam.org: The difference between idle-based suspend and opportunistic suspend is that the former will continue to wake up for timers and will never be entered if something is using CPU, whereas the latter will be entered whenever no suspend blocks are held. The problem with opportunistic suspend is that you might make the decision to suspend simultaneusly with a wakeup event being received. Suspend blocks facilitate synchronisation between the kernel and userspace to ensure that all such events have been consumed and handld appropriately. Right, and then you start taking suspend blockers in kernel here and there which eventually interferes with runtime PM. Suspend blocks prevent system suspend, not any per-device suspend. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, 2010-06-06 at 17:46 +0200, Thomas Gleixner wrote: On Sun, 6 Jun 2010, James Bottomley wrote: 3. We've lost sight of one of the original goals, which was to bring the android tree close enough to the kernel so that the android downstream driver and board producers don't have to choose between the android kernel and vanilla kernel. There are two ways to do that w/o creating a dependcy on anything. 1) merge the drivers w/o the suspend_blockers. It's not rocket science to have a patch which brings them back for android. Well, we sort of tried this when Greg pulled some of them into the staging tree. The problem is that without the annotations, the drivers are still different, and patches won't apply, so, unsurprisingly, they didn't get improved or even maintained. 2) merge the drivers with empty stub implementations for annotation. android just has to patch in the real one. That's also possible. This time, we would have a cosmetically closer tree ... however, what's in the kernel wouldn't be compilable for android ... which is where all the downstream wants to test, so they'd still be building for the android tree ... we just might have an easier time of it picking up their fixes. While I'd prefer #1, I' not in the way of #2. I think 1 is unviable ... I'm not opposed to 2 but I'd like to try to get the kernel really closer to android before we go for the cosmetic only option. Both ways can get the drivers into the kernel and it could/should have been done right from the beginning, but now we face a situation where drivers are held hostage. Then we can sit down more relaxed and fix the stuff in a way which makes both sides happy. If we manage to replace them, we can deprecate the stub implementation and remove it after a grace period. If we rename them it's not an issue either. We can rename them right away to a qos interface, but that does not really make a difference. What we really want to avoid is implementing an user space contract in a frenzy which binds us forever. Well, that's why the QoS proposal ... it already has a userspace API ... we'd just be extending it for statistics, which looks like a wothwhile goal independent of android anyway. It's not the suspend_blockers which are the causing the nightmare, it's solely the drivers itself especially when there are different implementations in both trees. And frankly, the drivers in android are not in a shape which makes them flood in within 2 weeks. That's serious work to get them brushed up and polished. So that gives us quite a period of time to solve the suspend problem. Right, so the sooner we make it easier for the drivers to use the kernel as their main repository, the better. James -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
2010/6/6 Matthew Garrett mj...@srcf.ucam.org: Suspend blocks prevent system suspend, not any per-device suspend. Can you suspend a device which is holding a wake lock? ~Vitaly -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 06, 2010 at 07:21:49PM +0200, Vitaly Wool wrote: 2010/6/6 Matthew Garrett mj...@srcf.ucam.org: Suspend blocks prevent system suspend, not any per-device suspend. Can you suspend a device which is holding a wake lock? Yes. Suspend blocks are orthogonal to runtime PM. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
James, On Sun, 6 Jun 2010, James Bottomley wrote: On Sun, 2010-06-06 at 17:46 +0200, Thomas Gleixner wrote: On Sun, 6 Jun 2010, James Bottomley wrote: 3. We've lost sight of one of the original goals, which was to bring the android tree close enough to the kernel so that the android downstream driver and board producers don't have to choose between the android kernel and vanilla kernel. There are two ways to do that w/o creating a dependcy on anything. 1) merge the drivers w/o the suspend_blockers. It's not rocket science to have a patch which brings them back for android. Well, we sort of tried this when Greg pulled some of them into the staging tree. The problem is that without the annotations, the drivers are still different, and patches won't apply, so, unsurprisingly, they didn't get improved or even maintained. 2) merge the drivers with empty stub implementations for annotation. android just has to patch in the real one. That's also possible. This time, we would have a cosmetically closer tree ... however, what's in the kernel wouldn't be compilable for android ... which is where all the downstream wants to test, so they'd still be building for the android tree ... we just might have an easier time of it picking up their fixes. The downstream users will be bound to the android tree anyway until the full set of drivers for a given platform is completely merged. So optimistically that would be 2.6.36, which gives us a couple of months to sort out the whole thing. Once a driver is merged mainline and the android tree switched over to use the mainline version, fixes can be sent both ways and that's not a real problem. While I'd prefer #1, I' not in the way of #2. I think 1 is unviable ... I'm not opposed to 2 but I'd like to try to get the kernel really closer to android before we go for the cosmetic only option. Both ways can get the drivers into the kernel and it could/should have been done right from the beginning, but now we face a situation where drivers are held hostage. Then we can sit down more relaxed and fix the stuff in a way which makes both sides happy. If we manage to replace them, we can deprecate the stub implementation and remove it after a grace period. If we rename them it's not an issue either. We can rename them right away to a qos interface, but that does not really make a difference. What we really want to avoid is implementing an user space contract in a frenzy which binds us forever. Well, that's why the QoS proposal ... it already has a userspace API ... we'd just be extending it for statistics, which looks like a wothwhile goal independent of android anyway. Right, but there is no dependency for the driver merge on that. It's not the suspend_blockers which are the causing the nightmare, it's solely the drivers itself especially when there are different implementations in both trees. And frankly, the drivers in android are not in a shape which makes them flood in within 2 weeks. That's serious work to get them brushed up and polished. So that gives us quite a period of time to solve the suspend problem. Right, so the sooner we make it easier for the drivers to use the kernel as their main repository, the better. Yep, the fastest way is to provide two stub inlines in pm.h and let the driver flood come in. I think all of us involved in that can do with a break, where we sit back, calm down and rethink w/o time pressure. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner t...@linutronix.de wrote: Right, so the sooner we make it easier for the drivers to use the kernel as their main repository, the better. Yep, the fastest way is to provide two stub inlines in pm.h and let the driver flood come in. As mentioned previously, we didn't know this was an option (stubs without an implementation behind them). If it is, and thus we can simplify the driver merging process short-term while sorting out a long-term implementation or replacement for suspend blockers, then I think we're making real progress. There is no reason that drivers that support suspend blockers cannot (or should not) support regular suspend/resume or runtime suspend/resume, so that shouldn't be a worry. The various operating modes complement, not compete with each other (we want the lowest possible power consumption in all states, be that fully active, fully suspended, or anything in between -- I think everyone involved agrees with this). I think all of us involved in that can do with a break, where we sit back, calm down and rethink w/o time pressure. Total agreement. Brian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sunday 06 June 2010, Matthew Garrett wrote: On Sun, Jun 06, 2010 at 07:21:49PM +0200, Vitaly Wool wrote: 2010/6/6 Matthew Garrett mj...@srcf.ucam.org: Suspend blocks prevent system suspend, not any per-device suspend. Can you suspend a device which is holding a wake lock? Yes. Suspend blocks are orthogonal to runtime PM. Yes, they are. The idea that they would somehow interfere with runtime PM has always been pure nonsense. They wouldn't and there's no way in which they could. Whether or not they are really necessary to address the Android requirements is a different question, though, and I don't really think so right now. At least not in the form submitted by Arve. Also, there's some overlap between suspend blockers and the PM QoS framework, so it seems to be a good idea to extend PM QoS (which already is in the kernel) to express some requirements that suspend blockers are supposed to express. Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 06, 2010 at 12:08:34PM -0500, James Bottomley wrote: Well, we sort of tried this when Greg pulled some of them into the staging tree. The problem is that without the annotations, the drivers are still different, and patches won't apply, so, unsurprisingly, they didn't get improved or even maintained. Err, the biggest pile in staging was meta drivers like the binder or some oom killer magic which are flat out braindead and wrong and have no chance going into mainline anyway. That's something different from real hardware drivers, although a few of those made it into staging as well if I remember correctly. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 6, 2010 at 12:05 PM, Christoph Hellwig h...@infradead.org wrote: On Sun, Jun 06, 2010 at 12:08:34PM -0500, James Bottomley wrote: Well, we sort of tried this when Greg pulled some of them into the staging tree. The problem is that without the annotations, the drivers are still different, and patches won't apply, so, unsurprisingly, they didn't get improved or even maintained. Err, the biggest pile in staging was meta drivers like the binder or some oom killer magic which are flat out braindead and wrong and have no chance going into mainline anyway. That's something different from real hardware drivers, although a few of those made it into staging as well if I remember correctly. I was shocked when Greg pulled the binder driver and some of the other generic android drivers into staging, because it was always my assumption that nobody upstream would want them. We did get some bugfixes for the binder driver (thanks!) but the general reaction was pretty much the same as yours here. I then was relatively unsurprised when it was dropped (we find it useful, upstream finds it useless, not much else to say). The various SoC peripheral drivers are, I suspect, much less contentious (modulo suspend blocker usage and any necessary kernel style cleanup). Brian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 06, 2010 at 12:15:10PM -0700, Brian Swetland wrote: I was shocked when Greg pulled the binder driver and some of the other generic android drivers into staging, because it was always my assumption that nobody upstream would want them. We did get some bugfixes for the binder driver (thanks!) but the general reaction was pretty much the same as yours here. I then was relatively unsurprised when it was dropped (we find it useful, upstream finds it useless, not much else to say). The various SoC peripheral drivers are, I suspect, much less contentious (modulo suspend blocker usage and any necessary kernel style cleanup). Yes. That's what makes me wonder about some parts of the discussion here. Getting the drivers for one or more of the android plattforms in is not a problem. I'd say it could have easily been done with the manweeks spent arguing in this and related threads. The much bigger issues is to get android userspace running on a more or less vanilla kernel, that is withoutthe binder, without the rather interesting group ID based security hack^H^H^H^Hmodel, without the suspend blocker userspace API and so on, and so on. So for people who really care about running a mainline kernel on their android device doing that part first on a generic ARM board in qemu might be much better first step work. On the other hand I've heard that various hardware vendors or parties closed to them are rather annoyed by their drivers beeing stuck in the android tree - but that can be easily solved by getting removing the suspend blockers (at least temporarily), cleaning up a few bits here and there and getting them in. It's not rocket science to get support for ARM SOC number 1654 into the mainline kernel. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, 6 Jun 2010, Brian Swetland wrote: On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner t...@linutronix.de wrote: Right, so the sooner we make it easier for the drivers to use the kernel as their main repository, the better. Yep, the fastest way is to provide two stub inlines in pm.h and let the driver flood come in. As mentioned previously, we didn't know this was an option (stubs without an implementation behind them). If it is, and thus we can That's what Greg did when he pulled stuff into staging, but there is no reason not to do it outside of staging as well. We can simply put the stub functions into Documentation/feature-removal.txt to ensure that we don't forget about them :) simplify the driver merging process short-term while sorting out a long-term implementation or replacement for suspend blockers, then I think we're making real progress. Yes, that way we do not lose the annotations. Replacing them, ripping them out or whatever we agree on, is a nobrainer. But it gets the drivers into the tree, so they are usable outside of android as well and the delta between android and mainline shrinks significantly. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig h...@infradead.org wrote: Yes. That's what makes me wonder about some parts of the discussion here. Getting the drivers for one or more of the android plattforms in is not a problem. I'd say it could have easily been done with the manweeks spent arguing in this and related threads. The much bigger issues is to get android userspace running on a more or less vanilla kernel, that is withoutthe binder, without the rather interesting group ID based security hack^H^H^H^Hmodel, without the suspend blocker userspace API and so on, and so on. Somebody will have to broker a deal with the frameworks/apps folks to get rid of the binder. They like it a lot. Of course if somebody built a drop-in replacement for the userspace side that didn't require a kernel driver, had the same performance characteristics, solved the same problems, etc, they could probably make an argument for it (or just provide it as a drop-in replacement for people who want a more pure linux underneath Android, even if we didn't pick it up). The group ID stuff works incredibly well for gating device access -- we ensure that devices that need access from various processes end up with perms like 0660 root audio (say for a raw audio interface), and then we assure that processes which have the may use audio hardware permission are executed with audio as an additional group. We ended up using the same model to control socket, raw socket, and bt socket access because at the time we could not find a reasonable way to grant or exclude such permissions on a process by process basis. Maintaining about 20-30 lines of diffs to make that work was not a bad tradeoff (and we don't expect those patches to go upstream). If there's a way to accomplish this without patching the kernel, we're all ears. While we do maintain some assorted patches to core code (like the permissions thing), we strongly prefer to keep our work localized to drivers (generic to android or specific to hardware), and try to migrate to common kernel features when possible, submit patches (like work Mike Chan is doing around cpufreq and power measurement), etc. Patches to core code cause more headaches when we rebase up to new kernel versions, after all. So for people who really care about running a mainline kernel on their android device doing that part first on a generic ARM board in qemu might be much better first step work. On the other hand I've heard that various hardware vendors or parties closed to them are rather annoyed by their drivers beeing stuck in the android tree - but that can be easily solved by getting removing the suspend blockers (at least temporarily), cleaning up a few bits here and there and getting them in. This continues to baffle me. If we (Google) are such a headache, why not just route around us. The drivers we've written are GPLv2, the source is out there for anyone who wants it, etc. The drivers other people have written we have no control over at all. From my point of view it'd be an annoyance if somebody took the code we wrote, modified it heavily, and pushed it upstream, but fundamentally I can't stop that from happening other than by pushing it upstream myself, first. Blaming me because you want me to send your drivers upstream and I'm not doing it or not doing it fast enough or not doing it the way you like does not seem very productive. I'm not a gatekeeper for patch submission to the mainline kernel. Brian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] suspend blockers Android integration
Brian, On Sun, 6 Jun 2010, Brian Swetland wrote: On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig h...@infradead.org wrote: Yes. That's what makes me wonder about some parts of the discussion here. Getting the drivers for one or more of the android plattforms in is not a problem. I'd say it could have easily been done with the manweeks spent arguing in this and related threads. The much bigger issues is to get android userspace running on a more or less vanilla kernel, that is withoutthe binder, without the rather interesting group ID based security hack^H^H^H^Hmodel, without the suspend blocker userspace API and so on, and so on. Somebody will have to broker a deal with the frameworks/apps folks to get rid of the binder. They like it a lot. Of course if somebody built a drop-in replacement for the userspace side that didn't require a kernel driver, had the same performance characteristics, solved the same problems, etc, they could probably make an argument for it (or just provide it as a drop-in replacement for people who want a more pure linux underneath Android, even if we didn't pick it up). The group ID stuff works incredibly well for gating device access -- we ensure that devices that need access from various processes end up with perms like 0660 root audio (say for a raw audio interface), and then we assure that processes which have the may use audio hardware permission are executed with audio as an additional group. We ended up using the same model to control socket, raw socket, and bt socket access because at the time we could not find a reasonable way to grant or exclude such permissions on a process by process basis. Maintaining about 20-30 lines of diffs to make that work was not a bad tradeoff (and we don't expect those patches to go upstream). If there's a way to accomplish this without patching the kernel, we're all ears. While we do maintain some assorted patches to core code (like the permissions thing), we strongly prefer to keep our work localized to drivers (generic to android or specific to hardware), and try to migrate to common kernel features when possible, submit patches (like work Mike Chan is doing around cpufreq and power measurement), etc. Patches to core code cause more headaches when we rebase up to new kernel versions, after all. thanks for the honest answer and thanks to Christoph for the reminder! That takes a lot of the bullshit arguments about downstream users being hurt out of the discussion. The above problems are way more complex to resolve than the suspend blocker details. That's another prove why we can let the drivers flow in (in the worst case w/o the suspend blocker stubs) and have no pressure to resolve the suspend blocker problem yesterday. That said, after thinking more about it, I'm advocating the stubs solution with a clear removal / decision date constraint (e.g. 2.6.37), as it forces all involved parties to stay tuned and not to forget about it. I'm curious about the outcome :) Thanks, tglx
Re: [linux-pm] suspend blockers Android integration
On Sun, 6 Jun 2010, Matthew Garrett wrote: The difference between idle-based suspend and opportunistic suspend is that the former will continue to wake up for timers and will never be entered if something is using CPU, whereas the latter will be entered whenever no suspend blocks are held. The problem with opportunistic suspend is that you might make the decision to suspend simultaneusly with a wakeup event being received. Suspend blocks facilitate synchronisation between the kernel and userspace to ensure that all such events have been consumed and handld appropriately. Remember that suspend takes place in several phases, the first of which is to freeze tasks. The phases can be controlled individually by the process carrying out a suspend, and there's nothing to prevent you from stopping after the freezer phase. Devices won't get powered down, but Android uses aggressive runtime power management for its devices anyway. If you do this then the synchronization can be carried out entirely from userspace, with no need for kernel modifications such as suspend blockers. And since Android can reach essentially the same low-power state from idle as from suspend, it appears that they really don't need any kernel changes at all. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
