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: suspend blockers Android integration
Hi! We started here because it's possibly the only api level change we have -- almost everything else is driver or subarch type work or controversial but entirely self-contained (like the binder, which I would be shocked to see ever hit mainline). [...] So why arent those bits mainline? It's a 1000 times easier to get drivers and small improvements and non-ABI changes upstream. After basically two years of growing your fork (and some attempts to get your drivers into drivers/staging/ - from where they have meanwhile dropped out again) you re-started with the worst possible thing to merge: a big and difficult kernel feature affecting many subsystems. Why? Because a large number of our drivers depend on it. The dependencies are trivial. Last time I checked, you had about 150KLoC drivers, with about 100 lines depending on wakelock support -- I know, I cleaned it up from staging. The changes required for merging 150KLoC will be definitely much bigger than 100 lines... -- (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 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: suspend blockers Android integration
On Tuesday 08 June 2010, Arve Hjønnevåg wrote: 2010/6/6 Rafael J. Wysocki r...@sisk.pl: On Sunday 06 June 2010, Arve Hjønnevåg wrote: ... If individual processes are frozen, we run into problems that we cannot run into if we freeze and thaw all processes. Not individual processes, but the processes that don't use wakelocks in the Android world all together. And of course the approach has to be different, because it's a different design, but I don't think there are any fundamental issues you can't solve within this approach. The app that reads this event blocks suspend before reading it. If it was busy talking to a less trusted app when the event happened it still works since all apps are running at this point. And how is this different from an approach with cgroup freezing? Apps that use wakelock within the current framework would use freeze locks to prevent the untrusted part of user space from being frozen or to thaw it. Where's the problem, then? They will not be able to get wakeup events directly from the kernel. If the kernel does not thaw processes when a wakeup event happens, the app may never get to the point where it grabs its wakelock. The apps that use freeze locks (or wakelocks) are never frozen, so I don't think this would be a problem. 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 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: suspend blockers Android integration
2010/6/5 Alan Stern st...@rowland.harvard.edu: On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: Yes, we can keep all our user space suspend blockers and thaw the frozen cgroup when any suspend blocker is held, but this would eliminate any power advantage that freezing a cgroup has over using suspend to freeze all processes. Without annotating the drivers to block the cgroup freezing in the same places as we now block suspend, it also prevents processes in the cgroup that we freeze from directly consuming wakup events. The driver annotations don't need to block the cgroup freezing. They just need to keep the system running long enough to awaken a thread that will handle the wakeup event. (See below.) A pm-qos constraint is good enough for this. I'm not sure what you mean by this, either you need to annotate the drivers or you don't. 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. This breaks existing apps. It effectively requires that a process that use suspend blocker do no work that does not block suspend. 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. This would create a minefield of possible deadlocks. You now have to make sure that your trusted threads do not share any locks with your untrusted threads. For instance you cannot safely call into the heap while any threads in your process are frozen. 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. And, it does not solve the problem for systems that enters lower power states from suspend than it can from idle. The last point my not be relevant to android anymore, but desktop systems already have auto suspend and it would be preferable to have a race free kernel api for this. This is an entirely different matter from the rest of the discussion. It would be better to consider this separately after Android's current problems have been addressed. Yes there has not been much discussion about this, but I don't understand why not. Automatic suspend is used outside Android, and it has the same race conditions that suspend blockers fix. -- 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
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: suspend blockers Android integration
2010/6/6 Thomas Gleixner t...@linutronix.de: On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: 2010/6/5 Thomas Gleixner t...@linutronix.de: On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: 2010/6/5 Thomas Gleixner t...@linutronix.de: On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: That download might take a minute or two, but that's not an justification for the crapplication to run unconfined and prevent lower power states. I agree, but this is not a simple problem to solve. Not with suspend blockers, but with cgroup confinement of crap, it's straight forward. I don't think is is straight forward. If the a process in the frozen group holds a resource that a process in the unfrozen group needs, how do deal with that? I'm going to fix the framework which puts the group into freeze state w/o making sure that there is no held shared resource. Come on it's not rocket science. I'm not sure which framework you are talking about here, but I don't think there is a single framework that knows about all shared resources. Damn, it's not me talking about our framework, you are mentioning when it fits your needs. You said you were going to fix the framework. I did know if you were talking about the cgroup framework, or the android user-space frameworks. I don't think either has knowledge about all shared resources. The cgroup freezer makes sure that there are no in kernel resources blocked. Of course the user space side has to do the same and it's not rocket science. It is much easier to make sure there are no kernel resources held than that there are no resources held in user-space. The kernel threads have to return to a safe location before they get frozen, where user threads are just frozen wherever they are. -- 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, 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: suspend blockers Android integration
2010/6/6 Thomas Gleixner t...@linutronix.de: On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: 2010/6/5 Thomas Gleixner t...@linutronix.de: Can you please explain in a consistent way how the application stack and the underlying framework (which exists according to android docs) is handling events and how the separation of trust level works ? I don't think I can, since I only know small parts of it. I know some Sigh, thats the whole reason why this discussion goes nowhere. Please keep in mind that we also have third party applications and that it is not acceptable to break them. So even if I was able to tell you everything our framework does, you still need to make sure your solution does not break existing apps. How in heavens sake should we be able to decide whether suspend blockers are the right and only thing which solves a problem, when the folks advocating suspend blockers are not able to explain the problem in the first place ? events like input event go though a single thread in our system process, while other events like network packets (which are also wakeup events) goes directly to the app. Yes, we know that already, but that's a completely useless information as it does not describe the full constraints and dependencies. Lemme summarize: Android needs suspend blockers, because it works, but cannot explain why it works and why it only works that way. A brilliant argument to merge them - NOT. Your solution changes the programming model in a way that suspend does not. Linux allow processes to communicate with each other, and if you freeze individual processes this breaks. For the android framework code a lack of a timely response from an application is treated as an error, and the user is notified that the application is misbehaving. It may be possible to change the framework to make sure that no processes are frozen while it is waiting for a response, but this is a major change and applications that receive wakeup events directly from the kernel will still be broken. -- 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
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: suspend blockers Android integration
2010/6/6 Rafael J. Wysocki r...@sisk.pl: On Sunday 06 June 2010, Arve Hjønnevåg wrote: 2010/6/5 Rafael J. Wysocki r...@sisk.pl: On Saturday 05 June 2010, Arve Hjønnevåg wrote: 2010/6/5 Thomas Gleixner t...@linutronix.de: B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote: ... Arve, we're still learning you have some more requirements we had no idea What new requirement are you talking about. Did you assume all our user-space ipc calls went though a single process? No, but I didn't assume that your wakelock-holding processes depend on the other processes in a way that might prevent them from acquiring or dropping a wakelock. It does not prevent it from acquiring a wakelock (assuming the already held wakelock does not have a timeout), but it could delay it and cause an error dialog to pop up stating that the fozen app is misbehaving. ... Trusted code that calls into untrusted code has to deal with the untrusted code not responding, but we only want to pop up a message that the application is not responding if it is misbehaving, not just because it was frozen though no fault of its own. When Android starts opportunistic suspend, all applications are frozen, trusted as well as untrusted, right? So, after they are all frozen, none of them can do anything to prevent suspend from happening, right? Not if you mean when we write to /sys/power/state. Processes are not frozen until the last suspend blocker is released. That doesn't matter. In the opportunistic mode you don't need to write into /sys/power/state to start suspend, this is done by the kernel automatically as soon as the last wakelock has been released (at least this is my assumption about how this works). Now, at this point the processes that don't use wakelocks can't really prevent themselves from being frozen and only the wakelocks users can do that. So, if a wakelock user depends on a process that doesn't use wakelocks in such a way that (because of that dependence) it can't acquire its wakelock while processes are being frozen, things don't work as they are supposed to. You seem to forget that we use overlapping wakelocks. A process that need to acquire a wakelock does so before the driver it talks to releases its wakelock. At this point no processes are frozen. Now, in my proposed approach the untrusted apps are frozen exactly at the point Android would start opportunistic suspend and they wouldn't be able to do anything about that anyway. So if one of your trusted apps depends on the untrusted ones in a way that you describe, you alread have a bug (the trusted app cannot prevent automatic suspend from happening even if it wants, because it depends on an untrusted app that has just been frozen). I don't think what you said here is correct. If a wakeup event happens all processed are unfrozen since the driver blocks suspend. This only means that the theoretical failure you gave as an example doesn't happen in practice. No problem, then. :-) If individual processes are frozen, we run into problems that we cannot run into if we freeze and thaw all processes. The app that reads this event blocks suspend before reading it. If it was busy talking to a less trusted app when the event happened it still works since all apps are running at this point. And how is this different from an approach with cgroup freezing? Apps that use wakelock within the current framework would use freeze locks to prevent the untrusted part of user space from being frozen or to thaw it. Where's the problem, then? They will not be able to get wakeup events directly from the kernel. If the kernel does not thaw processes when a wakeup event happens, the app may never get to the point where it grabs its wakelock. -- 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: suspend blockers Android integration
On Sun, Jun 6, 2010 at 7:43 AM, Matt Helsley matth...@us.ibm.com wrote: On Sun, Jun 06, 2010 at 12:36:21PM +0200, Thomas Gleixner wrote: On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: snip events like input event go though a single thread in our system process, while other events like network packets (which are also wakeup events) goes directly to the app. If you want to wake up cgroup-frozen tasks for these fds perhaps your framework can fcnt(fd, F_SETOWN, p[g]id) to send SIGIO to a How does the framework get all the fds that are used by the apps for wakeup events? userspace-suspend-blocker thread/process/process group. When IO comes in, the suspend blocker is signalled which then unfreezes the cgroup of the frozen untrusted task. SIGIO works on pipes, fifos, sockets, ttys, and ptys -- many of which are precisely the kinds of things that would connect [trusted and untrusted] apps. Notably absent (last I checked): inotify fds, signalfd, timerfd, eventfd, filesystem fds and likely more. Incidentally, this is just to show that it's not impossible to implement wakeups for cgroup-frozen tasks in userspace. Cheers, -Matt Helsley -- 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: suspend blockers Android integration
On Fri, 4 Jun 2010, Brian Swetland wrote: Yeah, I do understand that we're not making it easy for ourselves here. I think we hit the point where Rafael and Matthew signed off on things and thought aha, linux-pm maintainers are happy, now we're getting somewhere only to realize the light at the end of the tunnel was a bit further out than we anticipated ^^ What you missed is that the linux-pm maintainers have relativly little weight in getting things into the kernel. They are gatekeeper, so until they approve it there is basically no chance of getting in, but even changes that they develop and push frequently have a uphill battle to get into the kernel, especially if they would end up touching all drivers. There have been several proposals by the pm team that have been shot down much more completely than wavelocks. 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: suspend blockers Android integration
On Thu, 3 Jun 2010, Arjan van de Ven wrote: On Thu, 3 Jun 2010 19:26:50 -0700 (PDT) Linus Torvalds torva...@linux-foundation.org wrote: If the system is idle (or almost idle) for long times, I would heartily recommend actively shutting down unused cores. Some CPU's are hopefully smart enough to not even need that kind of software management, but I suspect even the really smart ones might be able to take advantage of the kernel saying: I'm shutting you down, you don't have to worry about latency AT ALL, because I'm keeping another CPU active to do any real work. sadly the reality is that offline is actually the same as deepest C state. At best. As far as I can see, this is at least true for all Intel and AMD cpus. And because there's then no power saving (but a performance cost), it's actually a negative for battery life/total energy. I believe that this assumes you are in the 'race to idle' situation where when you finish your work you can shutdown. If the work is ongoing you may never shutdown. Also, what about the new CPUs where you can ramp up the clockspeed on some cores if you hsut down other cores? that couls also benifit individual threads. 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 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: suspend blockers Android integration
On Thu, 3 Jun 2010, Linus Torvalds wrote: On Thu, 3 Jun 2010, Linus Torvalds wrote: so I'd like to see the opportunistc suspend thing think about CPU offlining Side note: one reason for me being somewhat interested in the CPU offlining is that I think the Android kind of opportunistic suspend is _not_ likely something I'd like to see on a desktop. But an the opportunistic CPU offliner? That might _well_ be useful even outside of any other suspend activity. When the OLPC was first released there was talk that the hardware was well designed for sleeping (including the ability for the display to keep going even if the system itself shut down), with the idealistic talk of the system possibly sleeping between keystrokes. things didn't end up working (a couple pieces of hardware ended up not playing well with others), but the concept is still something that could end up impacting users outside of the mobile phone market, even if not on your traditional desktop. 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 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: suspend blockers Android integration
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: 2010/6/5 Thomas Gleixner t...@linutronix.de: On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: That is too simple. You also have to prevent A from being frozen while it is processing the event or the result would be the same as if it was frozen beforehand. The framework decides when to freeze the app in the first place (as your framework does now when it decides to suspend) So it knows whether the app is frozen or not. So it knows damend well whether it processed the event or not. Our user-space code is not single-threaded. So just because an app was not frozen when you checked does not mean it will remain unfrozen. We can use the same user-space wakelock api we have now to prevent freezing apps instead of preventing suspend, but we loose any advantage we get from freezing just a subset of processes this way. Errm. That does not matter whether its single threaded or not. And right, you have to prevent that it gets frozen while you are calling into it. But that does not change the fact that you can do finer grained power control even in the case when suspend is impossible because a background application has work to finish and does that without requiring interaction with the frozen part. That's what I pointed out in the first place and you just argue in circles why it is impossible to do so. Let me recapitulate: Full on state: No difference because everything runs Full suspend state: No difference because everything is down Screen off, background work active: Suspend blocker held by the active background work lets other applications which are unrelated consume CPU cycles and power. versus Frozen apps restrict the CPU cycles and power consumption to the background work (if there are no interactions with frozen tasks) and therefor save more power than the on/off approach. If your user space stack cannot be distangled that way, then it's a problem of your user space stack and not changing the fact, that a well designedd system allows you to do that. Any objections ? Thanks, tglx
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: suspend blockers Android integration
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: 2010/6/5 Thomas Gleixner t...@linutronix.de: On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: 2010/6/5 Thomas Gleixner t...@linutronix.de: On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: That download might take a minute or two, but that's not an justification for the crapplication to run unconfined and prevent lower power states. I agree, but this is not a simple problem to solve. Not with suspend blockers, but with cgroup confinement of crap, it's straight forward. I don't think is is straight forward. If the a process in the frozen group holds a resource that a process in the unfrozen group needs, how do deal with that? I'm going to fix the framework which puts the group into freeze state w/o making sure that there is no held shared resource. Come on it's not rocket science. I'm not sure which framework you are talking about here, but I don't think there is a single framework that knows about all shared resources. Damn, it's not me talking about our framework, you are mentioning when it fits your needs. You said you were going to fix the framework. I did know if you were talking about the cgroup framework, or the android user-space frameworks. I don't think either has knowledge about all shared resources. The cgroup freezer makes sure that there are no in kernel resources blocked. Of course the user space side has to do the same and it's not rocket science. If you do not have a clearly defined user space framework, then we talk about a completely random conglomeration of applications which need to be brought into submission by some global brute force approach. I'm tired of this, really. You just use terminlology as it fits to defend the complete design failure of android. But you fail to trick me :) Can you please explain in a consistent way how the application stack and the underlying framework (which exists according to android docs) is handling events and how the separation of trust level works ? I don't think I can, since I only know small parts of it. I know some Sigh. That's the main reason why this discussion goes nowhere. How in heavens sake can we make a decision whether suspend blockers are the right and only way to go, when the people events like input event go though a single thread in our system process, while other events like network packets (which are also wakeup events) goes directly to the app.
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: suspend blockers Android integration
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: 2010/6/5 Thomas Gleixner t...@linutronix.de: Can you please explain in a consistent way how the application stack and the underlying framework (which exists according to android docs) is handling events and how the separation of trust level works ? I don't think I can, since I only know small parts of it. I know some Sigh, thats the whole reason why this discussion goes nowhere. How in heavens sake should we be able to decide whether suspend blockers are the right and only thing which solves a problem, when the folks advocating suspend blockers are not able to explain the problem in the first place ? events like input event go though a single thread in our system process, while other events like network packets (which are also wakeup events) goes directly to the app. Yes, we know that already, but that's a completely useless information as it does not describe the full constraints and dependencies. Lemme summarize: Android needs suspend blockers, because it works, but cannot explain why it works and why it only works that way. A brilliant argument to merge them - NOT. Thanks, tglx
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: suspend blockers Android integration
2010/6/6 Arjan van de Ven ar...@infradead.org: On Sat, 5 Jun 2010 14:26:14 -0700 Arve Hjønnevåg a...@android.com wrote: the kernel has a set of infrastructure already to help here (range timers, with which you can wakeup-limit untrusted userspace crap), timer slack for legacy background timers, etc etc. Range timers allows the kernel to align different timers so they don't each bring the cpu out of idle individually. They do not eliminate timers or make individual timers fire less often. you're incorrect. With range timers you can control the rate at which timers fire just fine. I was wondering... Currently GLib user-space aligns itself to fire burst of work at second boundaries without the need for IPC. But if you want to align beyond one second you need multi-process alignment. Say, one application says: wake me up between 30s and 1m. And the other one says: wake me up between 10m and 20m. They could very well align at some point if there was a central process keeping track of all the timers. Does the kernel provide something to solve that problem already? -- 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: suspend blockers Android integration
On Sun, 6 Jun 2010, Felipe Contreras wrote: 2010/6/6 Arjan van de Ven ar...@infradead.org: On Sat, 5 Jun 2010 14:26:14 -0700 Arve Hj?nnev?g a...@android.com wrote: the kernel has a set of infrastructure already to help here (range timers, with which you can wakeup-limit untrusted userspace crap), timer slack for legacy background timers, etc etc. Range timers allows the kernel to align different timers so they don't each bring the cpu out of idle individually. They do not eliminate timers or make individual timers fire less often. you're incorrect. With range timers you can control the rate at which timers fire just fine. I was wondering... Currently GLib user-space aligns itself to fire burst of work at second boundaries without the need for IPC. But if you want to align beyond one second you need multi-process alignment. Say, one application says: wake me up between 30s and 1m. And the other one says: wake me up between 10m and 20m. They could very well align at some point if there was a central process keeping track of all the timers. Does the kernel provide something to solve that problem already? yes,the kernel will let you say 'wake me in 10m, with a possible delay of up to 10 min' and get woken up between 10 and 20 min this is what was mentioned earlier in the thread where you could take an app that tries to do something every .1 second and set the kernel to allow the tick to be delayed for up to 3.9 seconds, resulting in a wakeup every 4 seconds if the system is idle. This has the additional advantage that if the system is not idle and other things are causing ticks to take place anyway, this app would get more ticks up to the 10/second it's asking for) 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: suspend blockers Android integration
On Sunday 06 June 2010, Arve Hjønnevåg wrote: 2010/6/5 Rafael J. Wysocki r...@sisk.pl: On Sunday 06 June 2010, Arve Hjønnevåg wrote: 2010/6/5 Rafael J. Wysocki r...@sisk.pl: On Saturday 05 June 2010, Arve Hjønnevåg wrote: 2010/6/4 Matt Helsley matth...@us.ibm.com: On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote: On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote: On Sat, 5 Jun 2010, Rafael J. Wysocki wrote: snip With the cgroup freezer you can suspend them right away and just keep the trusted background task(s) alive which allows us to go into deeper idle states instead of letting the crapplications run unconfined until the download finished and the suspend blocker goes away. Yes this would be better, but I want it in addition to suspend, not instead of it. It is also unclear if our user-space code could easily make use of it since our trusted code calls into untrusted code. Perhaps I'm misunderstanding, but suspend and the cgroup freezer interoperate well today -- you don't have to choose one or the other. If you've discovered otherwise I'd consider it a bug and would like to hear more about it. I'm not aware of any bug with combining both, but we cannot use suspend at all without suspend blockers in the kernel (since wakeup events may be ignored) The more I think of it, the more it appears to me that the problem of lost wakeup events can actually be solved without suspend blockers. I'll send a bunch of patches to address this issue, probably tomorrow. I know of two ways to prevent lost wakeup events. Reset a timeout every time you receive a wakeup event or prevents suspend until you know the event has been fully processed. Does your solution fall onto one of these two categories, or do you have a third way? Basically, it involves two mechanisms, detection of wakeup events occuring right before suspend is started This sounds like the timeout approach which I thought you did not like. and aborting suspend if wakeup events occur in the middle of it. Aborting suspend is easy, but when do you allow suspend again? I would recommend you to wait for the patches and then comment. :-) and I don't know how we can safely freeze cgroups without funneling all potential wakeup events through a process that never gets frozen. If your untrusted apps get called by the trusted ones, they aren't really untrusted in the first place. That is not a correct statement. A trusted apps can call into an untrusted app, it just has to validate the response and handle not getting a response at all. There are also different levels of trust. I may have trusted an app to provide a contact pictures, but not trusted it to block suspend. When the phone rings the app will be called to provide the picture for the incoming call dialog, but if it is frozen at this point the more trusted app that handles the incoming phone call will not be able to get the picture. It will be able to do that if it causes the frozen part of user space to be thawed. I think you have this problem already, though, because you use full system suspend and all of your apps are frozen by it. So, to handle the situation you describe above, you need to carry out full system resume that will thaw the tasks for you. I don't see any fundamental difference betwee the two cases. Yes, we can keep all our user space suspend blockers and thaw the frozen cgroup when any suspend blocker is held, but this would eliminate any power advantage that freezing a cgroup has over using suspend to freeze all processes. Why does it have to have _any_ power advantage? It's totally sufficient if it gives you approximately the same power savings. IOW, it doesn't have to be _better_ if it's acceptable to the kernel people at large. The rest of your objections have been addressed by Alan, so I'm not going to repeat his arguments. 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: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: suspend blockers Android integration
On Sunday 06 June 2010, Arve Hjønnevåg wrote: 2010/6/5 Rafael J. Wysocki r...@sisk.pl: On Saturday 05 June 2010, Arve Hjønnevåg wrote: 2010/6/5 Thomas Gleixner t...@linutronix.de: B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote: ... Arve, we're still learning you have some more requirements we had no idea What new requirement are you talking about. Did you assume all our user-space ipc calls went though a single process? No, but I didn't assume that your wakelock-holding processes depend on the other processes in a way that might prevent them from acquiring or dropping a wakelock. ... Trusted code that calls into untrusted code has to deal with the untrusted code not responding, but we only want to pop up a message that the application is not responding if it is misbehaving, not just because it was frozen though no fault of its own. When Android starts opportunistic suspend, all applications are frozen, trusted as well as untrusted, right? So, after they are all frozen, none of them can do anything to prevent suspend from happening, right? Not if you mean when we write to /sys/power/state. Processes are not frozen until the last suspend blocker is released. That doesn't matter. In the opportunistic mode you don't need to write into /sys/power/state to start suspend, this is done by the kernel automatically as soon as the last wakelock has been released (at least this is my assumption about how this works). Now, at this point the processes that don't use wakelocks can't really prevent themselves from being frozen and only the wakelocks users can do that. So, if a wakelock user depends on a process that doesn't use wakelocks in such a way that (because of that dependence) it can't acquire its wakelock while processes are being frozen, things don't work as they are supposed to. Now, in my proposed approach the untrusted apps are frozen exactly at the point Android would start opportunistic suspend and they wouldn't be able to do anything about that anyway. So if one of your trusted apps depends on the untrusted ones in a way that you describe, you alread have a bug (the trusted app cannot prevent automatic suspend from happening even if it wants, because it depends on an untrusted app that has just been frozen). I don't think what you said here is correct. If a wakeup event happens all processed are unfrozen since the driver blocks suspend. This only means that the theoretical failure you gave as an example doesn't happen in practice. No problem, then. :-) The app that reads this event blocks suspend before reading it. If it was busy talking to a less trusted app when the event happened it still works since all apps are running at this point. And how is this different from an approach with cgroup freezing? Apps that use wakelock within the current framework would use freeze locks to prevent the untrusted part of user space from being frozen or to thaw it. Where's the problem, then? 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, 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: suspend blockers Android integration
On Sun, Jun 06, 2010 at 12:36:21PM +0200, Thomas Gleixner wrote: On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: snip events like input event go though a single thread in our system process, while other events like network packets (which are also wakeup events) goes directly to the app. If you want to wake up cgroup-frozen tasks for these fds perhaps your framework can fcnt(fd, F_SETOWN, p[g]id) to send SIGIO to a userspace-suspend-blocker thread/process/process group. When IO comes in, the suspend blocker is signalled which then unfreezes the cgroup of the frozen untrusted task. SIGIO works on pipes, fifos, sockets, ttys, and ptys -- many of which are precisely the kinds of things that would connect [trusted and untrusted] apps. Notably absent (last I checked): inotify fds, signalfd, timerfd, eventfd, filesystem fds and likely more. Incidentally, this is just to show that it's not impossible to implement wakeups for cgroup-frozen tasks in userspace. Cheers, -Matt Helsley -- 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
