Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
Hi! (ok, so I'm little late to the party). > > Nonsense, if we want to push the system into suspend from the idle > > state we can do that. It's just not implemented and we've never tried > > to do it as it requires a non trivial amount of work, but I have done > > it on an ARM two years ago as a prove of concept and it works like a > > charm. > > ACPI provides no guarantees about what level of hardware functionality > remains during S3. You don't have any useful ability to determine which > events will generate wakeups. And from a purely practical point of view, We'll need ACPI extensions, then (or very conservative drivers). suspend blockers do *not* help here. > since the latency is in the range of seconds, you'll never have a low > enough wakeup rate to hit it. I did 'sleepy linux' prototype on PC, and yes I was able to get to 'once in 5 seconds' wakeup rate... good enough... 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, Jun 5, 2010 at 11:50 PM, Florian Mickler wrote: > On Sat, 5 Jun 2010 23:06:03 +0300 > Felipe Contreras wrote: >> How would such stats be calculated? I presume at regular intervals you >> check which applications are holding suspend blockers and increase a >> counter. >> >> How would you do that with the dynamic PM approach? At regular >> intervals you check for which applications are running (not idle). > > IIRC, the patches discussed have debugging infrastructure in > them. The kernel does the accounting. We are not talking about debugging, we are talking about stats shown in user-space so that users can see the offending apps. It doesn't matter where the accounting is done, it would be at regular intervals and there's nothing that prevents the dynamic PM approach to offer similar stats. >> > The only difference is, that with suspend blockers, he can than >> > dismiss the applications permission to block suspend and will not miss >> > his job interview the next day because his phones battery run >> > out. And also he can use the application to a certain extent. >> >> So the difference is between removing the app, and making it run >> crappy. I don't think that's a strong argument in favor of suspend >> blockers. >> > If you think a little about it, it is. Because if the app wouldn't be > usable at all, the bug wouldn't get fixed because the user wouldn't use > it. Or not? I'm not sure what's your point here. One user not using a certain application doesn't prevent bugs to get fixed. In fact, less people using an app will cause less buzz, and less downloads, and less positive votes... which might wake up the author to think: hey, maybe I'm doing something wrong? Maybe I should really listen to those bug reports. Anyway, my point is that there's nothing special about 3rd party app stats with suspend blockers. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, 5 Jun 2010 22:56:45 +0300 Felipe Contreras wrote: > On Sat, Jun 5, 2010 at 10:49 PM, Florian Mickler wrote: > > On Sat, 5 Jun 2010 20:16:33 +0300 > > Felipe Contreras wrote: > >> New users will see it has low score; they will not install it. That's > >> a network effect. > >> > >> Having users is the quintessential reason people write code. > > > > That is nice. But how does it impact the problem that suspend blockers > > solve? And why do suspend blockers interfere with that? > > It doesn't, I don't know why people keep bringing this argument, I > just though it should not be left open as a valid one. > > I should have mentioned that this is indeed irrelevant. > Uh! I found out how this is relevant to the suspend blockers case. Because not having users means that the bugs don't get fixed. Whereas in the suspend blockers case the users can use the app and get the bugs fixed. Cheers, Flo p.s.: I really wished you would focus more on solving the problem and not on dismissing it. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, 5 Jun 2010, Florian Mickler wrote: > On Sat, 5 Jun 2010 23:24:40 +0200 (CEST) > Thomas Gleixner wrote: > > > Stop that advertising campaing already. > > Stop advertising that there is no problem. > > > > > No thanks, > > > > tglx > > Cheers, > Flo > > (Sorry, crossfire. Caused > by you answering in the wrong subthread. I know that you are > engineering and not dismissing the problem. This was pointed at > Felipes "There is no problem"/"suspend blockers don't do what they are > designed to do well") Welcome to my killfile. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, 5 Jun 2010 23:24:40 +0200 (CEST) Thomas Gleixner wrote: > Stop that advertising campaing already. Stop advertising that there is no problem. > > No thanks, > > tglx Cheers, Flo (Sorry, crossfire. Caused by you answering in the wrong subthread. I know that you are engineering and not dismissing the problem. This was pointed at Felipes "There is no problem"/"suspend blockers don't do what they are designed to do well") -- 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, 5 Jun 2010, Florian Mickler wrote: > On Sat, 5 Jun 2010 23:26:27 +0300 > Felipe Contreras wrote: > > > Supposing there's a perfect usage of suspend blockers from user-space > > on current x86 platforms (in theory Android would have that), is the > > benefit that big to consider this a strong argument in favor of > > suspend blockers? Considering the small amount of x86 platforms using > > Android (is there any?), the fact that nobody else will use suspend > > blockers, and that x86 is already being fixed (as mentioned many times > > before) so dynamic PM is possible, I don't think we should be > > considering current x86 at all for suspend blockers. > > A solution for the desktop to deprecate having to shut down the > machine would not be that bad, wouldn;t it? (Why have I to shut down > my machine anyway?) > > In my opinion such a decision (when to shutdown) has to be guided by > userspace knowledge. > Future x86 hardware is to be fixed (as I read in this discussion), so > using suspend blockers could be the tool of choice. > > But alright. Let's be a little bit more focused on the present > situation: > > 1) There currently is no other solution. Wrong. The solutions are there, just being refused. > 2) It is a first stepping stone to bringing android to mainline. Crap. Once we have an userspace API we are bound to it. Period. Also there is no technical reason why the whole driver stack cannot be merged w/o the suspend blockers. > 3) Any "perfect" solution will emerge anyway. As there are so many > people with so strong opinions engaged in this discussion, I'm > confident. Yes, and that needs cooperation and compromises from both sides and not just blindly defining that there is no other solution. > 4) If there is a better solution, android will shurely adapt it as > soon as it is there. Sure, after we accepted the crap there is no incentive at all. Stop that advertising campaing already. No 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, 5 Jun 2010 23:26:27 +0300 Felipe Contreras wrote: > Supposing there's a perfect usage of suspend blockers from user-space > on current x86 platforms (in theory Android would have that), is the > benefit that big to consider this a strong argument in favor of > suspend blockers? Considering the small amount of x86 platforms using > Android (is there any?), the fact that nobody else will use suspend > blockers, and that x86 is already being fixed (as mentioned many times > before) so dynamic PM is possible, I don't think we should be > considering current x86 at all for suspend blockers. A solution for the desktop to deprecate having to shut down the machine would not be that bad, wouldn;t it? (Why have I to shut down my machine anyway?) In my opinion such a decision (when to shutdown) has to be guided by userspace knowledge. Future x86 hardware is to be fixed (as I read in this discussion), so using suspend blockers could be the tool of choice. But alright. Let's be a little bit more focused on the present situation: 1) There currently is no other solution. 2) It is a first stepping stone to bringing android to mainline. 3) Any "perfect" solution will emerge anyway. As there are so many people with so strong opinions engaged in this discussion, I'm confident. 4) If there is a better solution, android will shurely adapt it as soon as it is there. 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, 5 Jun 2010 23:06:03 +0300 Felipe Contreras wrote: > On Sat, Jun 5, 2010 at 10:56 PM, Florian Mickler wrote: > > On Sat, 5 Jun 2010 20:30:40 +0300 > > Felipe Contreras wrote: > >> I don't think the suspend blockers solve much. A bad application will > >> behave bad on any system. Suppose somebody decides to port Firefox to > >> Android, and forgets to listen to the screen off event (bad on Android > >> or Maemo), however, notices the application behaves very badly, so by > >> googling finds these suspend blockers, and enables them all the time > >> the application runs. > >> > >> When the user install the application, will be greeted by a warning > >> "This application might break PM, do you want to enable suspend > >> blockers?" (or whatever), as any typical user would do, will press Yes > >> (whatever). > >> > >> We end up in exactly the same situation. > >> > > No. The application will show up in the suspend blocker stats and the > > user will remember: "Oh, yes. There was a warning about that. Well I > > think I'm going to file a bug there." > > How would such stats be calculated? I presume at regular intervals you > check which applications are holding suspend blockers and increase a > counter. > > How would you do that with the dynamic PM approach? At regular > intervals you check for which applications are running (not idle). IIRC, the patches discussed have debugging infrastructure in them. The kernel does the accounting. > > > The only difference is, that with suspend blockers, he can than > > dismiss the applications permission to block suspend and will not miss > > his job interview the next day because his phones battery run > > out. And also he can use the application to a certain extent. > > So the difference is between removing the app, and making it run > crappy. I don't think that's a strong argument in favor of suspend > blockers. > If you think a little about it, it is. Because if the app wouldn't be usable at all, the bug wouldn't get fixed because the user wouldn't use it. Or not? 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, Jun 5, 2010 at 11:01 PM, Florian Mickler wrote: > On Sat, 5 Jun 2010 20:44:24 +0300 > Felipe Contreras wrote: > >> 2010/6/2 Arve Hjønnevåg : >> > 2010/6/2 Peter Zijlstra : >> >> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're >> >> fixing it, get over it already). >> >> >> > >> > I don't think it is realistic to drop support for all existing hardware. >> >> We are talking about mainline here, there's no support for suspend >> blockers, so nothing is dropped. >> >> In the mind of everybody, suspend blockers is for opportunistic >> suspend, which only makes sense on sensible hw (not current x86). So >> in the mind of everybody, x86 should be out of scope for the analysis >> of suspend blockers. >> >> Are you seriously suggesting that one of the strong arguments in favor >> of suspend blockers is x86 usage (nobody agrees)? If not, then drop >> it. > > I think they have an advantage over the > 30-minute-screensaver-then-suspend that current desktops do. Because > you can define what keeps the system up. I.e. the > screensaver/powermanager is not limited to keyboard- and > mouse-inactivity. What prevents you from defining other things keeping the system up right now? Nothing. It's up to user-space to decide when to suspend. In fact applications already block suspend; Transmission has the option to block suspend when downloading torrents. >> If I enable suspend blockers on my laptop, I have to modify my >> user-space. Otherwise my system will behave horribly. >> > > In the simplest case you have a shell script which takes a suspend > blocker and reads from stdinput. When you write "mem" to it, it > releases the suspend blocker and acquires it back again. Voila, forced > suspend reimplemented on top of opportunistic suspend. > > That wasn't hard, was it? Not hard, but still a modification of user-space, and a pretty bad one because it will prevent typical forced suspend, and typical suspend delaying (like with Transmission). Supposing the opportunistic suspend doesn't block the forced suspend, still, absolutely nothing will be achieved by enabling suspend blockers. If you want to take even a minimal advantage of suspend blockers you need serious modifications to user-space. Supposing there's a perfect usage of suspend blockers from user-space on current x86 platforms (in theory Android would have that), is the benefit that big to consider this a strong argument in favor of suspend blockers? Considering the small amount of x86 platforms using Android (is there any?), the fact that nobody else will use suspend blockers, and that x86 is already being fixed (as mentioned many times before) so dynamic PM is possible, I don't think we should be considering current x86 at all for suspend blockers. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, Jun 5, 2010 at 10:56 PM, Florian Mickler wrote: > On Sat, 5 Jun 2010 20:30:40 +0300 > Felipe Contreras wrote: >> I don't think the suspend blockers solve much. A bad application will >> behave bad on any system. Suppose somebody decides to port Firefox to >> Android, and forgets to listen to the screen off event (bad on Android >> or Maemo), however, notices the application behaves very badly, so by >> googling finds these suspend blockers, and enables them all the time >> the application runs. >> >> When the user install the application, will be greeted by a warning >> "This application might break PM, do you want to enable suspend >> blockers?" (or whatever), as any typical user would do, will press Yes >> (whatever). >> >> We end up in exactly the same situation. >> > No. The application will show up in the suspend blocker stats and the > user will remember: "Oh, yes. There was a warning about that. Well I > think I'm going to file a bug there." How would such stats be calculated? I presume at regular intervals you check which applications are holding suspend blockers and increase a counter. How would you do that with the dynamic PM approach? At regular intervals you check for which applications are running (not idle). > The only difference is, that with suspend blockers, he can than > dismiss the applications permission to block suspend and will not miss > his job interview the next day because his phones battery run > out. And also he can use the application to a certain extent. So the difference is between removing the app, and making it run crappy. I don't think that's a strong argument in favor of suspend blockers. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, 5 Jun 2010 20:44:24 +0300 Felipe Contreras wrote: > 2010/6/2 Arve Hjønnevåg : > > 2010/6/2 Peter Zijlstra : > >> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're > >> fixing it, get over it already). > >> > > > > I don't think it is realistic to drop support for all existing hardware. > > We are talking about mainline here, there's no support for suspend > blockers, so nothing is dropped. > > In the mind of everybody, suspend blockers is for opportunistic > suspend, which only makes sense on sensible hw (not current x86). So > in the mind of everybody, x86 should be out of scope for the analysis > of suspend blockers. > > Are you seriously suggesting that one of the strong arguments in favor > of suspend blockers is x86 usage (nobody agrees)? If not, then drop > it. I think they have an advantage over the 30-minute-screensaver-then-suspend that current desktops do. Because you can define what keeps the system up. I.e. the screensaver/powermanager is not limited to keyboard- and mouse-inactivity. > If I enable suspend blockers on my laptop, I have to modify my > user-space. Otherwise my system will behave horribly. > In the simplest case you have a shell script which takes a suspend blocker and reads from stdinput. When you write "mem" to it, it releases the suspend blocker and acquires it back again. Voila, forced suspend reimplemented on top of opportunistic suspend. That wasn't hard, was it? 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, Jun 5, 2010 at 10:49 PM, Florian Mickler wrote: > On Sat, 5 Jun 2010 20:16:33 +0300 > Felipe Contreras wrote: >> New users will see it has low score; they will not install it. That's >> a network effect. >> >> Having users is the quintessential reason people write code. > > That is nice. But how does it impact the problem that suspend blockers > solve? And why do suspend blockers interfere with that? It doesn't, I don't know why people keep bringing this argument, I just though it should not be left open as a valid one. I should have mentioned that this is indeed irrelevant. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, 5 Jun 2010 20:30:40 +0300 Felipe Contreras wrote: > On Thu, Jun 3, 2010 at 6:28 PM, Peter Zijlstra wrote: > > On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote: > >> On Thu, 03 Jun 2010 09:40:02 +0200 > >> Peter Zijlstra wrote: > >> > >> > Fix the friggin apps, don't kludge with freezing. > >> > >> Of course programs should be as smart as possible. But that is an > >> orthogonal problem. > >> > >> Suppose firefox were fixed. It still needs to fetch my rss feeds every > >> minute, because I'm sad if it doesn't. It just can't be fixed at the > >> application level. > > > > Sure it can, why would it need to fetch RSS feeds when the screen is off > > and nobody could possible see the result? So you can stop the timer when > > you know the window isn't visible or alternatively when the screensaver > > is active, I think most desktops have notification of that as well. > > Exactly, and that's what applications in the N900 do. For this to work > reliably, you need these notifications (network disconnected, screen > off) to be easily accessible, and even transparent to the application > writer. > > I don't think the suspend blockers solve much. A bad application will > behave bad on any system. Suppose somebody decides to port Firefox to > Android, and forgets to listen to the screen off event (bad on Android > or Maemo), however, notices the application behaves very badly, so by > googling finds these suspend blockers, and enables them all the time > the application runs. > > When the user install the application, will be greeted by a warning > "This application might break PM, do you want to enable suspend > blockers?" (or whatever), as any typical user would do, will press Yes > (whatever). > > We end up in exactly the same situation. > No. The application will show up in the suspend blocker stats and the user will remember: "Oh, yes. There was a warning about that. Well I think I'm going to file a bug there." The only difference is, that with suspend blockers, he can than dismiss the applications permission to block suspend and will not miss his job interview the next day because his phones battery run out. And also he can use the application to a certain extent. 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, Jun 5, 2010 at 10:04 PM, Rafael J. Wysocki wrote: > On Saturday 05 June 2010, Felipe Contreras wrote: >> On Mon, May 31, 2010 at 11:47 PM, Florian Mickler >> wrote: >> > On Mon, 31 May 2010 22:12:19 +0200 >> > Florian Mickler wrote: >> >> If I have a simple shell script then I don't wanna jump through >> >> hoops just to please your fragile kernel. >> > >> > Also why should that code on one device kill my uptime and on the >> > other machine (my wall-plugged desktop) work just well? That doesn't >> > sound right. >> >> Sounds perfectly right to me; one code runs perfectly fine on one >> machine, and on the other doesn't even compile. Well, sure, it wasn't >> written with that use-case in mind. >> >> > Clearly opportunistic suspend is a workaround for battery-driven devices >> > and no general solution. But it is not specific to android. At least >> > not inherently. It could be useful for any embedded or mobile device >> > where you can clearly distinguish important functions from convenience >> > functions. >> >> Yes, it could, but why go for the hacky solution when we know how to >> achieve the ideal one? >> >> > I really can't understand the whole _fundamental_ opposition to this >> > design choice. >> >> Nobody is using it, except Android. Nobody will use it, except Android. > > That's like saying "Android is not a legitimate user of the kernel". Is that > you wanted to say? Read the context: opportunistic suspend, which is considered a workaround, which requires new user-space API for suspend blockers, might be remotely considered for inclusion *if* it indeed solves a problem for battery-driven devices, which other parties also experience and could benefit from this solution. The answer: no, it doesn't: only Android user-space will benefit from it. >> I have seen recent proposals that don't require changing the whole >> user-space. That might actually be used by other players. > > Sure, an approach benefitting more platforms than just Android would be > better, > but saying that the kernel shouldn't address the Android's specific needs as a > rule if no one else has those needs too is quite too far reaching to me. There are no Android specific needs, why should certain user-space ecosystem need certain API that somehow *nobody* else does? I think in this huge thread it has become obvious that people are reluctant to this idea... whatever problem Android user-space presents (I don't think there's any), it can be solved for "he rest of the world" too, and such generic solution is worth exploring. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, 2010-06-05 at 21:39 +0200, Rafael J. Wysocki wrote: > > There is a number of kernel users that depend on Android user space > (phone vendors using Android on their hardware, but providing their own > drivers), so I don't think we really can identify Android with Google in that > respect. I don't see why we can't merge the platform code and drivers without suspend blockers. Google can patch them back in on their side if they want to. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, 5 Jun 2010 20:16:33 +0300 Felipe Contreras wrote: > On Tue, Jun 1, 2010 at 12:14 AM, Rafael J. Wysocki wrote: > > Do you realistically think that by hurting the _user_ you will make the > > _developer_ write better code? No, really. > > As an application writer, if my users complain that their battery is > being drained (as it happened), they stop using it, and other people > see there are problems, so they stop using it, if people get angry > about it they will vote it down. > > New users will see it has low score; they will not install it. That's > a network effect. > > Having users is the quintessential reason people write code. > That is nice. But how does it impact the problem that suspend blockers solve? And why do suspend blockers interfere with that? 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] [PATCH 0/8] Suspend block api (version 8)
On Saturday 05 June 2010, Peter Zijlstra wrote: > On Sat, 2010-06-05 at 21:04 +0200, Rafael J. Wysocki wrote: > > > > > I have seen recent proposals that don't require changing the whole > > > user-space. That might actually be used by other players. > > > > Sure, an approach benefitting more platforms than just Android would be > > better, > > but saying that the kernel shouldn't address the Android's specific needs > > as a > > rule if no one else has those needs too is quite too far reaching to me. > > Well, if the android people keep rejecting all sensible approaches to > power savings except their suspend blocker mess, then I don't see why we > should support their ill designed mess. Well, I certainly would like the Android people to be more appreciative of our ideas if they expect reciprocity. > We should strive to provide an interface that can be used by all > interested parties to conserve power; if Android really is the only > possible user of the interface then I don't see any reason at all to > merge it, they might as well keep it in their private tree. There is a number of kernel users that depend on Android user space (phone vendors using Android on their hardware, but providing their own drivers), so I don't think we really can identify Android with Google in that respect. 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] [PATCH 0/8] Suspend block api (version 8)
On Sat, 2010-06-05 at 21:04 +0200, Rafael J. Wysocki wrote: > > > I have seen recent proposals that don't require changing the whole > > user-space. That might actually be used by other players. > > Sure, an approach benefitting more platforms than just Android would be > better, > but saying that the kernel shouldn't address the Android's specific needs as a > rule if no one else has those needs too is quite too far reaching to me. Well, if the android people keep rejecting all sensible approaches to power savings except their suspend blocker mess, then I don't see why we should support their ill designed mess. We should strive to provide an interface that can be used by all interested parties to conserve power; if Android really is the only possible user of the interface then I don't see any reason at all to merge it, they might as well keep it in their private tree. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Saturday 05 June 2010, Felipe Contreras wrote: > On Mon, May 31, 2010 at 11:47 PM, Florian Mickler wrote: > > On Mon, 31 May 2010 22:12:19 +0200 > > Florian Mickler wrote: > >> If I have a simple shell script then I don't wanna jump through > >> hoops just to please your fragile kernel. > > > > Also why should that code on one device kill my uptime and on the > > other machine (my wall-plugged desktop) work just well? That doesn't > > sound right. > > Sounds perfectly right to me; one code runs perfectly fine on one > machine, and on the other doesn't even compile. Well, sure, it wasn't > written with that use-case in mind. > > > Clearly opportunistic suspend is a workaround for battery-driven devices > > and no general solution. But it is not specific to android. At least > > not inherently. It could be useful for any embedded or mobile device > > where you can clearly distinguish important functions from convenience > > functions. > > Yes, it could, but why go for the hacky solution when we know how to > achieve the ideal one? > > > I really can't understand the whole _fundamental_ opposition to this > > design choice. > > Nobody is using it, except Android. Nobody will use it, except Android. That's like saying "Android is not a legitimate user of the kernel". Is that you wanted to say? > I have seen recent proposals that don't require changing the whole > user-space. That might actually be used by other players. Sure, an approach benefitting more platforms than just Android would be better, but saying that the kernel shouldn't address the Android's specific needs as a rule if no one else has those needs too is quite too far reaching 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] [PATCH 0/8] Suspend block api (version 8)
2010/6/2 Arve Hjønnevåg : > 2010/6/2 Peter Zijlstra : >> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're >> fixing it, get over it already). >> > > I don't think it is realistic to drop support for all existing hardware. We are talking about mainline here, there's no support for suspend blockers, so nothing is dropped. In the mind of everybody, suspend blockers is for opportunistic suspend, which only makes sense on sensible hw (not current x86). So in the mind of everybody, x86 should be out of scope for the analysis of suspend blockers. Are you seriously suggesting that one of the strong arguments in favor of suspend blockers is x86 usage (nobody agrees)? If not, then drop it. >>> Unrelated to >>> Android, I also want to use opportunistic suspend on my desktop. >> >> So you're going to sprinkle this suspend blocker shite all over regular >> userspace? > > I have said several times, that regular user-space will not need to be > modified to maintain their current behavior. If I enable suspend blockers on my laptop, I have to modify my user-space. Otherwise my system will behave horribly. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Thu, Jun 3, 2010 at 6:28 PM, Peter Zijlstra wrote: > On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote: >> On Thu, 03 Jun 2010 09:40:02 +0200 >> Peter Zijlstra wrote: >> >> > Same for firefox, you can teach it to not render animated gifs and run >> > javascript for invisible tabs, and once the screen-saver kicks in, >> > nothing is visible (and with X telling apps their window is visible or >> > not it knows), so it should go idle all of its own. >> > >> > Fix the friggin apps, don't kludge with freezing. >> >> Of course programs should be as smart as possible. But that is an >> orthogonal problem. >> >> Suppose firefox were fixed. It still needs to fetch my rss feeds every >> minute, because I'm sad if it doesn't. It just can't be fixed at the >> application level. > > Sure it can, why would it need to fetch RSS feeds when the screen is off > and nobody could possible see the result? So you can stop the timer when > you know the window isn't visible or alternatively when the screensaver > is active, I think most desktops have notification of that as well. Exactly, and that's what applications in the N900 do. For this to work reliably, you need these notifications (network disconnected, screen off) to be easily accessible, and even transparent to the application writer. I don't think the suspend blockers solve much. A bad application will behave bad on any system. Suppose somebody decides to port Firefox to Android, and forgets to listen to the screen off event (bad on Android or Maemo), however, notices the application behaves very badly, so by googling finds these suspend blockers, and enables them all the time the application runs. When the user install the application, will be greeted by a warning "This application might break PM, do you want to enable suspend blockers?" (or whatever), as any typical user would do, will press Yes (whatever). We end up in exactly the same situation. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Tue, Jun 1, 2010 at 12:14 AM, Rafael J. Wysocki wrote: > Do you realistically think that by hurting the _user_ you will make the > _developer_ write better code? No, really. As an application writer, if my users complain that their battery is being drained (as it happened), they stop using it, and other people see there are problems, so they stop using it, if people get angry about it they will vote it down. New users will see it has low score; they will not install it. That's a network effect. Having users is the quintessential reason people write code. > If the user likes the app very much (or depends on it or whatever makes him > use it), he will rather switch the platform to one that allows him to run that > app without _visible_ problems than complain to the developer, because _the_ > _user_ _doesn't_ _realize_ that the app is broken. From the user's > perspective, the platform that has problems with the app is broken, because > the app apparently runs without problems on concurrent platforms. Yeah, right. I don't think anybody has every bought an iPhone because of Tweetie. People care how the applications run on their phones, not how their phone's platform runs their favorite application, in fact, most probably it became their favorite application because it was running great on their phone, and they wouldn't expect it to run on phones with other platforms. Either applications run on S60, iPhone OS, Android, or Maemo, but not in a combination of those. And if their certain app that runs on multiple platforms, and the user actually knows that (probably a geek), then he knows he can't expect it to work exactly the same. > The whole "no reason to tolerate broken apps" midset is simply misguided IMO, > because it's based on unrealistic assumptions. That's because in general > users > only need the platform for running apps they like (or need or whatever). If > they can't run apps they like on a given platform, or it is too painful to > them > to run their apps on it, they will rather switch to another platform than stop > using the apps. You seriously think people switch high-end phones just to run their favorite apps? It's much cheaper to switch apps, and that's what users do. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Mon, May 31, 2010 at 11:47 PM, Florian Mickler wrote: > On Mon, 31 May 2010 22:12:19 +0200 > Florian Mickler wrote: >> If I have a simple shell script then I don't wanna jump through >> hoops just to please your fragile kernel. > > Also why should that code on one device kill my uptime and on the > other machine (my wall-plugged desktop) work just well? That doesn't > sound right. Sounds perfectly right to me; one code runs perfectly fine on one machine, and on the other doesn't even compile. Well, sure, it wasn't written with that use-case in mind. > Clearly opportunistic suspend is a workaround for battery-driven devices > and no general solution. But it is not specific to android. At least > not inherently. It could be useful for any embedded or mobile device > where you can clearly distinguish important functions from convenience > functions. Yes, it could, but why go for the hacky solution when we know how to achieve the ideal one? > I really can't understand the whole _fundamental_ opposition to this > design choice. Nobody is using it, except Android. Nobody will use it, except Android. I have seen recent proposals that don't require changing the whole user-space. That might actually be used by other players. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Mon, May 31, 2010 at 8:55 AM, Igor Stoppa wrote: > ext Felipe Contreras wrote: > >> I think this information can be obtained dynamically while the >> application is running, > > yes, that was the idea > >> and perhaps the limits can be stored. It would >> be pretty difficult for the applications to give this kind of >> information because there are so many variables. >> >> For example, an media player can tell you: this clip has 24 fps, but >> if the user is moving the time slider, the fps would increase and drop >> very rapidly, and how much depends at least on the container format >> and type of seek. >> > > I doubt that belongs to typical QoS. Maybe the target could be to be able to > decode a sequence of i-frames? I'm not sure what you mean. I-frames comes usually one per second, so if you only decode I-frames, your experience would be really bad. Moreover, you don't know beforehand when an I-frame is coming, only when it's there, and some clips can have only one I-frame at the beginning. >> A game or a telephony app could tell you "I need real-time priority" >> but so much as giving the details of latency and bandwidth? I find >> that very unlikely. >> > > from my gaming days the games were still evaluated in fps ... maybe i made > the wrong assumption? Yes, the more fps, the better, but you calculate that by counting the amount of frames rendered over a period of time; you know the fps *after* the fact. > A telephony app should still be able to tell if it's dropping audio frames. Yes, which could be unrelated to PM, like bad network conditions, but yeah, it should also be able to tell if the problem is with the application itself (audio decoder too slow). > In all cases there should be some device independent limit - like: what is > the sort of degradation that is considered acceptable by the typical user? It is easy to tell after the PM actions have been made, as in "wait! I'm not able to perform gimme more power!". But I don't see how that could be done _before_ the PM actions are done. >From all the QoS proposals I have seen here, and considering that some people said that suspend blockers could be a specific case of QOS, I don't think people have been considering QoS as something to state _after_. > Tuning might be offered, but at least this should set some sane set of > defaults. Huh? Defaults in what units, based on what, and when and how to update? Cheers. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Thu, 03 Jun 2010 17:28:01 +0200 Peter Zijlstra wrote: > On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote: > > On Thu, 03 Jun 2010 09:40:02 +0200 > > Peter Zijlstra wrote: > > > > > Same for firefox, you can teach it to not render animated gifs and run > > > javascript for invisible tabs, and once the screen-saver kicks in, > > > nothing is visible (and with X telling apps their window is visible or > > > not it knows), so it should go idle all of its own. > > > > > > Fix the friggin apps, don't kludge with freezing. > > > > Of course programs should be as smart as possible. But that is an > > orthogonal problem. > > > > Suppose firefox were fixed. It still needs to fetch my rss feeds every > > minute, because I'm sad if it doesn't. It just can't be fixed at the > > application level. > > Sure it can, why would it need to fetch RSS feeds when the screen is off > and nobody could possible see the result? So you can stop the timer when > you know the window isn't visible or alternatively when the screensaver > is active, I think most desktops have notification of that as well. This is arguing on a very thin line. In fact it is becoming pointless. Suppose there were an RSS-feed plugin that signals events to an event Plugin. That event plugin could be either visual notification or sending audio-signals. But the RSS feed doesn't know what specific plugin it talks to. So screen off is _not always_ the right indicator. Sometimes it is, sometimes it's not. There would be a seperate infrastructure needed in the program to tell the different plugins that the core thinks everything should stop. How does the core knows when to stop? And then there probably need to be some kind of "suspend blockers" in the program. *g* Just solve it at the right level, so that the apps don't need to be infected with this shit. And this belongs between the iron and the apps. And it seems it needs to be some cooperative approach of kernel and userspace-framework as it isn't right to put that much policy in the kernel. I don't think it is a black and white thing, where you can just say "fix the friggin apps". And this is a really f*beep*ng serious point. (at least to me) 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/4 Dmitry Torokhov : > On Wed, Jun 02, 2010 at 07:44:59PM -0700, Arve Hjønnevåg wrote: >> On Wed, Jun 2, 2010 at 4:32 PM, Dmitry Torokhov >> wrote: >> > On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote: >> >> On Wed, 2 Jun 2010 21:02:24 +1000 >> >> Neil Brown wrote: >> >> > >> >> > And this decision (to block suspend) really needs to be made in the >> >> > driver, >> >> > not in userspace? >> >> >> >> Well, it fits. The requirement is a direct consequence of the intimate >> >> knowledge the driver has about the driven devices. >> > >> > That is not really true. A driver does have intimate knowledge of the >> > device, however it does not necessarily have an idea about the data read >> > from the device. Consider the gpio_matrix driver: Arve says that it has >> > to continue scanning matrix once first interrupt arrvies. But it really >> > depends on what key has been pressed - if user pressed KEY_SUSPEND or >> > KEY_POWER it cmight be better if we did not wait for key release but >> > initiated the action right away. The decision on how system reacts to a >> > key press does not belong to the driver but really to userspace. >> >> If we just suspend while the keypad scan is active, a second press of >> KEY_POWER would not be able wake the device up. The gpio keypad matrix >> driver has two operating modes. No keys are pressed: all the outputs >> are active so a key press will generate an interrupt in one of the >> inputs. Keys are pressed: Activate a single output at a time so we can >> determine which keys are pressed. The second mode is entered when the >> driver gets an interrupt in the first mode. The first mode is entered >> if the scan detected that no keys are pressed. The driver could be >> modified to stop the scan on suspend and forcibly put the device back >> in no-keys-pressed state, but pressing additional keys connected to >> the same input can no longer generate any events (the input does not >> change). > > Would that be still the case if you reprogram the device as wakeup > source while suspending? It depends on what part you are referring to. It is impossible to detect some keys presses if you suspend while a key is held down. That key will connect one output to one input. If the interrupt is edge triggered you can just turn all the outputs back on (and clear the interrupt that this will generate) and suspend, but no additional key presses on keys connected to the same input will cause an interrupt until all those keys have been released first or a key connected to another input is pressed. If the interrupt is level triggered (and fixed polarity) you cannot do this. You must either disable the input interrupt or the output. This means that you if the user releases the key and press it again, you cannot wakeup on this key. You can also not wake up on any other keys connected to the disables input or output. So you have some choice in what events you loose, but there will always be some key press sequence that will not work if you suspend but will work if you prevent suspend in the middle. > > Anyway, it does not really matter. Your case (current suspend blockers) > would delay putting device to sleep till you release all the keys, > including KEY_POWER. If you delegate the decision to userspace it would > have an _option_ of putting the device to sleep earlier, however in both > cases user has to release all keys before the device can be resumed. We deliver all keys to user space so that is has the option of reacting to them. Yes if we did not do this user space would have the option of suspending while keys are pressed, but it would need detailed knowledge about the driver to make this decision (will the driver loose key events if we suspend, which keys can be lost, does the condition clear automatically when all the keys are released or do we need another wakeup event to get out of it). -- 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 02, 2010 at 07:44:59PM -0700, Arve Hjønnevåg wrote: > On Wed, Jun 2, 2010 at 4:32 PM, Dmitry Torokhov > wrote: > > On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote: > >> On Wed, 2 Jun 2010 21:02:24 +1000 > >> Neil Brown wrote: > >> > > >> > And this decision (to block suspend) really needs to be made in the > >> > driver, > >> > not in userspace? > >> > >> Well, it fits. The requirement is a direct consequence of the intimate > >> knowledge the driver has about the driven devices. > > > > That is not really true. A driver does have intimate knowledge of the > > device, however it does not necessarily have an idea about the data read > > from the device. Consider the gpio_matrix driver: Arve says that it has > > to continue scanning matrix once first interrupt arrvies. But it really > > depends on what key has been pressed - if user pressed KEY_SUSPEND or > > KEY_POWER it cmight be better if we did not wait for key release but > > initiated the action right away. The decision on how system reacts to a > > key press does not belong to the driver but really to userspace. > > If we just suspend while the keypad scan is active, a second press of > KEY_POWER would not be able wake the device up. The gpio keypad matrix > driver has two operating modes. No keys are pressed: all the outputs > are active so a key press will generate an interrupt in one of the > inputs. Keys are pressed: Activate a single output at a time so we can > determine which keys are pressed. The second mode is entered when the > driver gets an interrupt in the first mode. The first mode is entered > if the scan detected that no keys are pressed. The driver could be > modified to stop the scan on suspend and forcibly put the device back > in no-keys-pressed state, but pressing additional keys connected to > the same input can no longer generate any events (the input does not > change). Would that be still the case if you reprogram the device as wakeup source while suspending? Anyway, it does not really matter. Your case (current suspend blockers) would delay putting device to sleep till you release all the keys, including KEY_POWER. If you delegate the decision to userspace it would have an _option_ of putting the device to sleep earlier, however in both cases user has to release all keys before the device can be resumed. -- Dmitry -- 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] [PATCH 0/8] Suspend block api (version 8)
Yes, having a QoS parameter per-subsystem (or even per-device) is very important for SoCs that have independently controlled powerdomains. If all devices/subsystems in a particular powerdomain have QoS parameters that permit, the power state of that powerdomain can be lowered independently from system-wide power state and power states of other power domains. This seems similar to that pm_qos generalization into bus drivers we where waving our hands at during the collab summit in April? We never did get into meaningful detail at that time. --mgross I think there is definitely a need for QoS parameters per-device. I've been pondering how to incorporate this concept into runtime_pm. One idea would be to add pm_qos-like callbacks to struct dev_pm_ops, e.g. runtime_pm_qos_add/update/remove_requirement(). Requirements would be passed up the tree to the first parent that cares, usually a bus driver. Is this similar to what you guys were discussing at the collab summit? Thanks. - Bryan -- 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] [PATCH 0/8] Suspend block api (version 8)
Hi Kevin, Mark, all, Yes, from our brief discussions at ELC, and all the ensuing discussions that have happened in the last few weeks, it certainly seems like a good time to think about: - what is a good model to tie up device idleness, latencies, constraints with cpu idle infrastructure - extensions to PM_QOS, part of what is being discussed, especially Kevin's earlier mail about QOS parameter per subsystem/device that may have independent clock/power domain control. - what is a good infrastructure to subsequently allow platform-specific low power state - extensions to cpuidle infrastructure to allow platform-wide low power state? Exact conditions for such entry/exit into low power state (latency, wake, etc.) could be platform specific. Is it a good idea to discuss about a model that could be applicable to other SOCs/platforms as well? Thanks Rajeev -Original Message- From: linux-pm-boun...@lists.linux-foundation.org [mailto:linux-pm-boun...@lists.linux-foundation.org] On Behalf Of Kevin Hilman Sent: Thursday, June 03, 2010 10:28 PM To: Gross, Mark Cc: Neil Brown; ty...@mit.edu; Peter Zijlstra; felipe.ba...@nokia.com; LKML; Florian Mickler; James Bottomley; Thomas Gleixner; Linux OMAP Mailing List; Linux PM; Alan Cox Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) "Gross, Mark" writes: >>-Original Message- >>From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >>Sent: Thursday, June 03, 2010 7:43 AM >>To: Peter Zijlstra >>Cc: Alan Cox; Gross, Mark; Florian Mickler; James Bottomley; Arve >>Hjønnevåg; Neil Brown; ty...@mit.edu; LKML; Thomas Gleixner; Linux OMAP >>Mailing List; Linux PM; felipe.ba...@nokia.com >>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) >> >>Peter Zijlstra writes: >> >>> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: >>>> > [mtg: ] This has been a pain point for the PM_QOS implementation. >>>> They change the constrain back and forth at the transaction level of >>>> the i2c driver. The pm_qos code really wasn't made to deal with such >>>> hot path use, as each such change triggers a re-computation of what >>>> the aggregate qos request is. >>>> >>>> That should be trivial in the usual case because 99% of the time you can >>>> hot path >>>> >>>>the QoS entry changing is the latest one >>>>there have been no other changes >>>>If it is valid I can use the cached previous aggregate I cunningly >>>>saved in the top QoS entry when I computed the new one >>>> >>>> (ie most of the time from the kernel side you have a QoS stack) >>> >>> Why would the kernel change the QoS state of a task? Why not have two >>> interacting QoS variables, one for the task, one for the subsystem in >>> question, and the action depends on their relative value? >> >>Yes, having a QoS parameter per-subsystem (or even per-device) is very >>important for SoCs that have independently controlled powerdomains. >>If all devices/subsystems in a particular powerdomain have QoS >>parameters that permit, the power state of that powerdomain can be >>lowered independently from system-wide power state and power states of >>other power domains. >> > This seems similar to that pm_qos generalization into bus drivers we where > waving our hands at during the collab summit in April? We never did get > into meaningful detail at that time. The hand-waving was around how to generalize it into the driver-model, or PM QoS. We're already doing this for OMAP, but in an OMAP-specific way, but it's become clear that this is something useful to generalize. Kevin ___ linux-pm mailing list linux...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/linux-pm -- 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] [PATCH] - race-free suspend. Was: Re: [PATCH 0/8] Suspend block api (version 8)
On Thu, Jun 3, 2010 at 6:36 AM, mark gross <640e9...@gmail.com> wrote: > On Wed, Jun 02, 2010 at 11:12:39PM -0700, Brian Swetland wrote: >> On Wed, Jun 2, 2010 at 11:04 PM, mark gross <640e9...@gmail.com> wrote: >> >> >> >> There are many wakeup events possible in a typical system -- >> >> keypresses or other input events, network traffic, telephony events, >> >> media events (fill audio buffer, fill video decoder buffer, etc), and >> >> I think requiring that all wakeup event processing bottleneck through >> >> a single userspace process is non-optimal here. >> > >> > Um doesn't the android framework bottleneck the user mode lock >> > processing through the powermanager and any wake up event processing >> > eventually has to grab a lock through this bottleneck anyway? >> >> For "high level" framework/application level wakelocks, yes, but lower >> level components beneath the java api layer use the kernel interface >> directly. >> > Oh. I thought everything went through > hardware/libhardware_legacy/power/power.c > who else is hitting /sys/power/* in the android user mode then? I believe everything does -- that's the thin wrapper around the kernel interface (which will have to change slightly to meet the suspend_blocker device/fd vs wakelock proc/sys interface, etc), which is used by the powermanager service, the RIL, and any other low level code. At the App/Service level, wakelocks are provided by a java level API that is a remote interface to the powermanager. 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] [PATCH 0/8] Suspend block api (version 8)
On Thu, 2010-06-03 at 09:58 -0700, Kevin Hilman wrote: > "Gross, Mark" writes: > > >>-Original Message- > >>From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > >>Sent: Thursday, June 03, 2010 7:43 AM > >>To: Peter Zijlstra > >>Cc: Alan Cox; Gross, Mark; Florian Mickler; James Bottomley; Arve > >>Hjønnevåg; Neil Brown; ty...@mit.edu; LKML; Thomas Gleixner; Linux OMAP > >>Mailing List; Linux PM; felipe.ba...@nokia.com > >>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) > >> > >>Peter Zijlstra writes: > >> > >>> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: > >>>> > [mtg: ] This has been a pain point for the PM_QOS implementation. > >>>> They change the constrain back and forth at the transaction level of > >>>> the i2c driver. The pm_qos code really wasn't made to deal with such > >>>> hot path use, as each such change triggers a re-computation of what > >>>> the aggregate qos request is. > >>>> > >>>> That should be trivial in the usual case because 99% of the time you can > >>>> hot path > >>>> > >>>> the QoS entry changing is the latest one > >>>> there have been no other changes > >>>> If it is valid I can use the cached previous aggregate I cunningly > >>>> saved in the top QoS entry when I computed the new one > >>>> > >>>> (ie most of the time from the kernel side you have a QoS stack) > >>> > >>> Why would the kernel change the QoS state of a task? Why not have two > >>> interacting QoS variables, one for the task, one for the subsystem in > >>> question, and the action depends on their relative value? > >> > >>Yes, having a QoS parameter per-subsystem (or even per-device) is very > >>important for SoCs that have independently controlled powerdomains. > >>If all devices/subsystems in a particular powerdomain have QoS > >>parameters that permit, the power state of that powerdomain can be > >>lowered independently from system-wide power state and power states of > >>other power domains. > >> > > This seems similar to that pm_qos generalization into bus drivers we where > > waving our hands at during the collab summit in April? We never did get > > into meaningful detail at that time. > > The hand-waving was around how to generalize it into the driver-model, > or PM QoS. We're already doing this for OMAP, but in an OMAP-specific > way, but it's become clear that this is something useful to > generalize. Do you have a pointer to the source and description? It might be useful to look at to do a reality check on what we're talking about. 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] [PATCH 0/8] Suspend block api (version 8)
"Gross, Mark" writes: >>-Original Message- >>From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >>Sent: Thursday, June 03, 2010 7:43 AM >>To: Peter Zijlstra >>Cc: Alan Cox; Gross, Mark; Florian Mickler; James Bottomley; Arve >>Hjønnevåg; Neil Brown; ty...@mit.edu; LKML; Thomas Gleixner; Linux OMAP >>Mailing List; Linux PM; felipe.ba...@nokia.com >>Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) >> >>Peter Zijlstra writes: >> >>> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: >>>> > [mtg: ] This has been a pain point for the PM_QOS implementation. >>>> They change the constrain back and forth at the transaction level of >>>> the i2c driver. The pm_qos code really wasn't made to deal with such >>>> hot path use, as each such change triggers a re-computation of what >>>> the aggregate qos request is. >>>> >>>> That should be trivial in the usual case because 99% of the time you can >>>> hot path >>>> >>>>the QoS entry changing is the latest one >>>>there have been no other changes >>>>If it is valid I can use the cached previous aggregate I cunningly >>>>saved in the top QoS entry when I computed the new one >>>> >>>> (ie most of the time from the kernel side you have a QoS stack) >>> >>> Why would the kernel change the QoS state of a task? Why not have two >>> interacting QoS variables, one for the task, one for the subsystem in >>> question, and the action depends on their relative value? >> >>Yes, having a QoS parameter per-subsystem (or even per-device) is very >>important for SoCs that have independently controlled powerdomains. >>If all devices/subsystems in a particular powerdomain have QoS >>parameters that permit, the power state of that powerdomain can be >>lowered independently from system-wide power state and power states of >>other power domains. >> > This seems similar to that pm_qos generalization into bus drivers we where > waving our hands at during the collab summit in April? We never did get > into meaningful detail at that time. The hand-waving was around how to generalize it into the driver-model, or PM QoS. We're already doing this for OMAP, but in an OMAP-specific way, but it's become clear that this is something useful to generalize. Kevin -- 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] [PATCH 0/8] Suspend block api (version 8)
>-Original Message- >From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: Thursday, June 03, 2010 7:43 AM >To: Peter Zijlstra >Cc: Alan Cox; Gross, Mark; Florian Mickler; James Bottomley; Arve >Hjønnevåg; Neil Brown; ty...@mit.edu; LKML; Thomas Gleixner; Linux OMAP >Mailing List; Linux PM; felipe.ba...@nokia.com >Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) > >Peter Zijlstra writes: > >> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: >>> > [mtg: ] This has been a pain point for the PM_QOS implementation. >>> They change the constrain back and forth at the transaction level of >>> the i2c driver. The pm_qos code really wasn't made to deal with such >>> hot path use, as each such change triggers a re-computation of what >>> the aggregate qos request is. >>> >>> That should be trivial in the usual case because 99% of the time you can >>> hot path >>> >>> the QoS entry changing is the latest one >>> there have been no other changes >>> If it is valid I can use the cached previous aggregate I cunningly >>> saved in the top QoS entry when I computed the new one >>> >>> (ie most of the time from the kernel side you have a QoS stack) >> >> Why would the kernel change the QoS state of a task? Why not have two >> interacting QoS variables, one for the task, one for the subsystem in >> question, and the action depends on their relative value? > >Yes, having a QoS parameter per-subsystem (or even per-device) is very >important for SoCs that have independently controlled powerdomains. >If all devices/subsystems in a particular powerdomain have QoS >parameters that permit, the power state of that powerdomain can be >lowered independently from system-wide power state and power states of >other power domains. > This seems similar to that pm_qos generalization into bus drivers we where waving our hands at during the collab summit in April? We never did get into meaningful detail at that time. --mgross -- 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 2010-06-03 at 10:21 -0400, ty...@mit.edu wrote: > And let's be blunt. If in the future the Android team (which I'm not > a member of) decides that they have invested more engineering time > than they can justify from a business perspective, the next time > someone starts whining on a blog, or on Slashdot, or at a conference, > about how "OMG! Google is forking the kernel!!!", or "Google is > making the lives of device driver writers for the embedded world > difficult", it will now be possible from a political point of view to > point and the hundreds, if not thousands, of e-mail messages of LKML > developers wanting to redesign this effort and saying "Nyet! Nyet! > Nyet!" to the original patchset, to point out that Google has a made > an effort, and gone far beyond what is required by the GPL. Not only > has the source code been made available, but hundreds of engineering > hours have been made trying to accomodate the demands of LKML --- and > LKML has said no to suspend blockers/wakelocks. In the spirit of being blunt, so what? We say no for good technical reasons. Also when did it become sensible to push features after they were shipped? It never works to develop stuff like this out-of-tree and then push for inclusion. You always get to rewrite (at least 3 times). If Google indeed decides it doesn't want to play upstream, then sad. But I don't see how we would be unjust in complaining about it. There is more to our community than the letter of the GPL, and you should know that. So I really don't see the point of your argument (was there one besides the management gibberish?). -- 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] [PATCH 0/8] Suspend block api (version 8)
On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote: > On Thu, 03 Jun 2010 09:40:02 +0200 > Peter Zijlstra wrote: > > > Same for firefox, you can teach it to not render animated gifs and run > > javascript for invisible tabs, and once the screen-saver kicks in, > > nothing is visible (and with X telling apps their window is visible or > > not it knows), so it should go idle all of its own. > > > > Fix the friggin apps, don't kludge with freezing. > > Of course programs should be as smart as possible. But that is an > orthogonal problem. > > Suppose firefox were fixed. It still needs to fetch my rss feeds every > minute, because I'm sad if it doesn't. It just can't be fixed at the > application level. Sure it can, why would it need to fetch RSS feeds when the screen is off and nobody could possible see the result? So you can stop the timer when you know the window isn't visible or alternatively when the screensaver is active, I think most desktops have notification of that as well. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Thu, 2010-06-03 at 16:35 +0200, Thomas Gleixner wrote: > On Thu, 3 Jun 2010, James Bottomley wrote: > > > On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: > > > > [mtg: ] This has been a pain point for the PM_QOS implementation. They > > > > change the constrain back and forth at the transaction level of the i2c > > > > driver. The pm_qos code really wasn't made to deal with such hot path > > > > use, as each such change triggers a re-computation of what the > > > > aggregate qos request is. > > > > > > That should be trivial in the usual case because 99% of the time you can > > > hot path > > > > > > the QoS entry changing is the latest one > > > there have been no other changes > > > If it is valid I can use the cached previous aggregate I cunningly > > > saved in the top QoS entry when I computed the new one > > > > > > (ie most of the time from the kernel side you have a QoS stack) > > > > It's not just the list based computation: that's trivial to fix, as you > > say ... the other problem is the notifier chain, because that's blocking > > and could be long. Could we invoke the notifier through a workqueue? > > It doesn't seem to have veto power, so it's pure notification, does it > > matter if the notice is delayed (as long as it's in order)? > > It depends on the information type and for a lot of things we might > get away without notifiers. > > The only real issue is when you need to get other cores out of their > deep idle state to make a new constraint work. That's what we do with > the DMA latency notifier right now. But the only DMA latency notifier is cpuidle_latency_notifier. That looks callable from atomic context, so we could have two chains: one atomic and one not. The only other notifier in use is the ieee80211_max_network_latency, which uses mutexes, so does require user context. 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] [PATCH 0/8] Suspend block api (version 8)
Peter Zijlstra writes: > On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: >> > [mtg: ] This has been a pain point for the PM_QOS implementation. >> They change the constrain back and forth at the transaction level of >> the i2c driver. The pm_qos code really wasn't made to deal with such >> hot path use, as each such change triggers a re-computation of what >> the aggregate qos request is. >> >> That should be trivial in the usual case because 99% of the time you can >> hot path >> >> the QoS entry changing is the latest one >> there have been no other changes >> If it is valid I can use the cached previous aggregate I cunningly >> saved in the top QoS entry when I computed the new one >> >> (ie most of the time from the kernel side you have a QoS stack) > > Why would the kernel change the QoS state of a task? Why not have two > interacting QoS variables, one for the task, one for the subsystem in > question, and the action depends on their relative value? Yes, having a QoS parameter per-subsystem (or even per-device) is very important for SoCs that have independently controlled powerdomains. If all devices/subsystems in a particular powerdomain have QoS parameters that permit, the power state of that powerdomain can be lowered independently from system-wide power state and power states of other power domains. Kevin -- 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] [PATCH 0/8] Suspend block api (version 8)
On Thu, 3 Jun 2010, James Bottomley wrote: > On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: > > > [mtg: ] This has been a pain point for the PM_QOS implementation. They > > > change the constrain back and forth at the transaction level of the i2c > > > driver. The pm_qos code really wasn't made to deal with such hot path > > > use, as each such change triggers a re-computation of what the aggregate > > > qos request is. > > > > That should be trivial in the usual case because 99% of the time you can > > hot path > > > > the QoS entry changing is the latest one > > there have been no other changes > > If it is valid I can use the cached previous aggregate I cunningly > > saved in the top QoS entry when I computed the new one > > > > (ie most of the time from the kernel side you have a QoS stack) > > It's not just the list based computation: that's trivial to fix, as you > say ... the other problem is the notifier chain, because that's blocking > and could be long. Could we invoke the notifier through a workqueue? > It doesn't seem to have veto power, so it's pure notification, does it > matter if the notice is delayed (as long as it's in order)? It depends on the information type and for a lot of things we might get away without notifiers. The only real issue is when you need to get other cores out of their deep idle state to make a new constraint work. That's what we do with the DMA latency notifier right now. 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] [PATCH 0/8] Suspend block api (version 8)
>-Original Message- >From: James Bottomley [mailto:james.bottom...@suse.de] >Sent: Thursday, June 03, 2010 6:25 AM >To: Alan Cox >Cc: Gross, Mark; Florian Mickler; Arve Hjønnevåg; Neil Brown; >ty...@mit.edu; Peter Zijlstra; LKML; Thomas Gleixner; Linux OMAP Mailing >List; Linux PM; felipe.ba...@nokia.com >Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) > >On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: >> > [mtg: ] This has been a pain point for the PM_QOS implementation. They >change the constrain back and forth at the transaction level of the i2c >driver. The pm_qos code really wasn't made to deal with such hot path use, >as each such change triggers a re-computation of what the aggregate qos >request is. >> >> That should be trivial in the usual case because 99% of the time you can >> hot path >> >> the QoS entry changing is the latest one >> there have been no other changes >> If it is valid I can use the cached previous aggregate I cunningly >> saved in the top QoS entry when I computed the new one >> >> (ie most of the time from the kernel side you have a QoS stack) > >It's not just the list based computation: that's trivial to fix, as you >say ... the other problem is the notifier chain, because that's blocking >and could be long. Could we invoke the notifier through a workqueue? >It doesn't seem to have veto power, so it's pure notification, does it >matter if the notice is delayed (as long as it's in order)? [mtg: ] true. The notifications "could be" done on as a scheduled work item in most cases. I think there is only one user of the notification so far any way. Most pm_qos users do a pole of the current value for whatever parameter they are interested in. --mgross > >> > We've had a number of attempts at fixing this, but I think the proper >fix is to bolt a "disable C-states > x" interface into cpu_idle that >bypases pm_qos altogether. Or, perhaps add a new pm_qos API that does the >equivalent operation, overriding whatever constraint is active. >> >> We need some of this anyway for deep power saving because there is >> hardware which can't wake from soem states, which in turn means if that >> device is active we need to be above the state in question. > >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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 02, 2010 at 11:43:06PM -0700, Brian Swetland wrote: > > I guess it becomes an question of economics for you then. Does the cost of > > whatever user-space changes are required exceed the value of using an > > upstream > > kernel? Both the cost and the value would be very hard to estimate in > > advance. I don't envy you the decision... > > Well, at this point we've invested more engineering hours in the > various rewrites of this (single) patchset and discussion around it > than we have spent on rebasing our trees on roughly every other > mainline release since 2.6.16 or so, across five years of Android > development. We think there's some good value to be had (all the > usual reasons) by heading upstream, so we're still discussing these > patches and exploring alternatives, but yes, from one way of looking > at it, it'd certainly be cheaper to just keep maintaining our own > trees. And let's be blunt. If in the future the Android team (which I'm not a member of) decides that they have invested more engineering time than they can justify from a business perspective, the next time someone starts whining on a blog, or on Slashdot, or at a conference, about how "OMG! Google is forking the kernel!!!", or "Google is making the lives of device driver writers for the embedded world difficult", it will now be possible from a political point of view to point and the hundreds, if not thousands, of e-mail messages of LKML developers wanting to redesign this effort and saying "Nyet! Nyet! Nyet!" to the original patchset, to point out that Google has a made an effort, and gone far beyond what is required by the GPL. Not only has the source code been made available, but hundreds of engineering hours have been made trying to accomodate the demands of LKML --- and LKML has said no to suspend blockers/wakelocks. Realistically, a company makes decisions about whether to pursue engineering efforts based on business plans, and this is true whether the company is Red Hat, or Novell, or IBM, or Google. One of the cost/benefits can be things that aren't easily measured such as public relations. But past a certain point, it may be that the right answer is to make a single public appeal to Linus, and if he says no, or if he ignores the pull request, then the company at hand can say, "We've done the best that we could, but the Linux developer community, and Linus specifically, has refused our patch". And yes, it's all about PR, but let's not kid ourselves --- the GPL and bad PR can't be used as blackmail to force a company to invest arbitrarily unlimited amounts of engineering effort just to satisfy the mandarins of the LKML and/or Linus. And if people want to call this a fork, Linus has in the past said that sometimes forks are healthy, and necessary, and we can see how things play out in the marketplace. Disclosure: I work at Google, but I'm not at all involved in the Android development team, and it's not at all my call when Brian and his team should make a decision that they've invested more time/energy than can be justified to their management --- heck, they even roll up to an completely different VP than I do. :-) - Ted -- 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] [PATCH 0/8] Suspend block api (version 8)
On Thu, 03 Jun 2010 08:24:31 -0500 James Bottomley wrote: > On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: > > > [mtg: ] This has been a pain point for the PM_QOS implementation. They > > > change the constrain back and forth at the transaction level of the i2c > > > driver. The pm_qos code really wasn't made to deal with such hot path > > > use, as each such change triggers a re-computation of what the aggregate > > > qos request is. > > > > That should be trivial in the usual case because 99% of the time you can > > hot path > > > > the QoS entry changing is the latest one > > there have been no other changes > > If it is valid I can use the cached previous aggregate I cunningly > > saved in the top QoS entry when I computed the new one > > > > (ie most of the time from the kernel side you have a QoS stack) > > It's not just the list based computation: that's trivial to fix, as you > say ... the other problem is the notifier chain, because that's blocking > and could be long. Could we invoke the notifier through a workqueue? > It doesn't seem to have veto power, so it's pure notification, does it > matter if the notice is delayed (as long as it's in order)? I think schedule_work() (worqueue.h) can take care of that. Thats how the rfkill subsystem does it. 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] [PATCH 0/8] Suspend block api (version 8)
On Thu, 03 Jun 2010 09:40:02 +0200 Peter Zijlstra wrote: > Same for firefox, you can teach it to not render animated gifs and run > javascript for invisible tabs, and once the screen-saver kicks in, > nothing is visible (and with X telling apps their window is visible or > not it knows), so it should go idle all of its own. > > Fix the friggin apps, don't kludge with freezing. Of course programs should be as smart as possible. But that is an orthogonal problem. Suppose firefox were fixed. It still needs to fetch my rss feeds every minute, because I'm sad if it doesn't. It just can't be fixed at the application level. 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] [PATCH 0/8] Suspend block api (version 8)
> > > If "suspend" is the thing we are used to via > /sys/power/state then the > > > race will persist forever except for the suspend blocker workaround, True, because device wakeups are enabled by device.driver.suspend() methods, which are invoked towards the end of the activities triggered by writing /sys/power/state. Now, there can be platforms (mostly embedded) where the drivers adopt a policy that not only do they keep their devices in as low a power state as practical at all times, but they also keep the hardware wakeup mechanisms enabled (they may be needed to kick the hardware out of those low power states) ... That is, suspend() might be superfluous (a NOP) in those platforms' drivers. Such platforms might also be (non-ACPI) ones where idle C-states and S3/STR have the same power consumption ... but that would be a platform-specific issue, not a generic thing which all Linux implementations could rely on. - Dave -- 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] [PATCH] - race-free suspend. Was: Re: [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 02, 2010 at 11:12:39PM -0700, Brian Swetland wrote: > On Wed, Jun 2, 2010 at 11:04 PM, mark gross <640e9...@gmail.com> wrote: > >> > >> There are many wakeup events possible in a typical system -- > >> keypresses or other input events, network traffic, telephony events, > >> media events (fill audio buffer, fill video decoder buffer, etc), and > >> I think requiring that all wakeup event processing bottleneck through > >> a single userspace process is non-optimal here. > > > > Um doesn't the android framework bottleneck the user mode lock > > processing through the powermanager and any wake up event processing > > eventually has to grab a lock through this bottleneck anyway? > > For "high level" framework/application level wakelocks, yes, but lower > level components beneath the java api layer use the kernel interface > directly. > Oh. I thought everything went through hardware/libhardware_legacy/power/power.c who else is hitting /sys/power/* in the android user mode then? I'll have to go hunting for them I guess. --mgross -- 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] [PATCH 0/8] Suspend block api (version 8)
On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: > > [mtg: ] This has been a pain point for the PM_QOS implementation. They > > change the constrain back and forth at the transaction level of the i2c > > driver. The pm_qos code really wasn't made to deal with such hot path use, > > as each such change triggers a re-computation of what the aggregate qos > > request is. > > That should be trivial in the usual case because 99% of the time you can > hot path > > the QoS entry changing is the latest one > there have been no other changes > If it is valid I can use the cached previous aggregate I cunningly > saved in the top QoS entry when I computed the new one > > (ie most of the time from the kernel side you have a QoS stack) It's not just the list based computation: that's trivial to fix, as you say ... the other problem is the notifier chain, because that's blocking and could be long. Could we invoke the notifier through a workqueue? It doesn't seem to have veto power, so it's pure notification, does it matter if the notice is delayed (as long as it's in order)? > > We've had a number of attempts at fixing this, but I think the proper fix > > is to bolt a "disable C-states > x" interface into cpu_idle that bypases > > pm_qos altogether. Or, perhaps add a new pm_qos API that does the > > equivalent operation, overriding whatever constraint is active. > > We need some of this anyway for deep power saving because there is > hardware which can't wake from soem states, which in turn means if that > device is active we need to be above the state in question. 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] [PATCH 0/8] Suspend block api (version 8)
On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: > > [mtg: ] This has been a pain point for the PM_QOS implementation. > They change the constrain back and forth at the transaction level of > the i2c driver. The pm_qos code really wasn't made to deal with such > hot path use, as each such change triggers a re-computation of what > the aggregate qos request is. > > That should be trivial in the usual case because 99% of the time you can > hot path > > the QoS entry changing is the latest one > there have been no other changes > If it is valid I can use the cached previous aggregate I cunningly > saved in the top QoS entry when I computed the new one > > (ie most of the time from the kernel side you have a QoS stack) Why would the kernel change the QoS state of a task? Why not have two interacting QoS variables, one for the task, one for the subsystem in question, and the action depends on their relative value? > > We've had a number of attempts at fixing this, but I think the > proper fix is to bolt a "disable C-states > x" interface into cpu_idle > that bypases pm_qos altogether. Or, perhaps add a new pm_qos API that > does the equivalent operation, overriding whatever constraint is > active. > > We need some of this anyway for deep power saving because there is > hardware which can't wake from soem states, which in turn means if that > device is active we need to be above the state in question. Right, and I can imagine that depending on the platform details and not the device details, so we get platform hooks in the drivers, or possible up in the generic stack because I don't think NICs actually know if there are open connections. -- 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] [PATCH 0/8] Suspend block api (version 8)
> [mtg: ] This has been a pain point for the PM_QOS implementation. They > change the constrain back and forth at the transaction level of the i2c > driver. The pm_qos code really wasn't made to deal with such hot path use, > as each such change triggers a re-computation of what the aggregate qos > request is. That should be trivial in the usual case because 99% of the time you can hot path the QoS entry changing is the latest one there have been no other changes If it is valid I can use the cached previous aggregate I cunningly saved in the top QoS entry when I computed the new one (ie most of the time from the kernel side you have a QoS stack) > We've had a number of attempts at fixing this, but I think the proper fix is > to bolt a "disable C-states > x" interface into cpu_idle that bypases pm_qos > altogether. Or, perhaps add a new pm_qos API that does the equivalent > operation, overriding whatever constraint is active. We need some of this anyway for deep power saving because there is hardware which can't wake from soem states, which in turn means if that device is active we need to be above the state in question. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-06-02 at 23:58 -0700, Brian Swetland wrote: > > I haven't poked around too much with how things work in SMP > environments -- are there per-cpu idle threads? Yes, and we recently grew the infrastructure for asymmetric MP in the processing capacity sense. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-06-02 at 22:13 +0200, Florian Mickler wrote: > On Wed, 02 Jun 2010 12:21:28 +0200 > Peter Zijlstra wrote: > Do you switch your pc on and off manually? Sometimes? Really? > (if not, you are probably a kernel hacker *g*) Yeah, when my Radeon GPU locks up the bus _again_, and yeah to replace parts, but no, not otherwise ;-) But I've been doing that for pretty much as long as I've had a computer. > But the rest are usecases that are similar to the suspend-blocker > usecases. You know that you are not using the machine and going > through the pain to shut down your machine. You have to do it manually. > Why? Make suspend an idle state and teach apps to go real quiet. (Then again, that only really works when regular network packets can wake the machine for my case). > > This leads to having to sprinkle magic dust (and lots of config options) > > all over userspace. Something that gets esp interesting with only a > > boolean interface. > > A userspace daemon could keep track of what applications can be > ignored. The wordprocessor probably should not keep the system busy. As > well as a running firefox. > > It is a hard problem. But we have _no way of deciding any of this in > the kernel_ Therefore I say, fix the worprocessor to not actually do anything if its not poked at -- not too hard, wordprocessors really don't need to do anything on their own, and you can do your last backup cycle when the window becomes invisible and stop the timer until the document changes again. Same for firefox, you can teach it to not render animated gifs and run javascript for invisible tabs, and once the screen-saver kicks in, nothing is visible (and with X telling apps their window is visible or not it knows), so it should go idle all of its own. Fix the friggin apps, don't kludge with freezing. You really only ever want to freeze broken apps. And even for those I would prefer it if I got notified some app is stupid, then I could either fix it, or choose not to use it. You can also teach cron to listen to dbus messages telling it about the screen state and postpone jobs -- but please make that a configurable thing, I really like all that work done at 4am when I'm (usually) not around to be bothered by it. > The problem is there independently of suspend blockers. If the system > can suspend with network up, then you shure as hell want to suspend > even if the network is up. So it would actually be a reason for any > kind of "suspend blockers" scheme. Wouldn't it? Well, at that point suspend is nothing more than an idle state, and platform code needs to somehow inform the idle state governor that active net connections need to prevent that idle state from being used. If you want to call that suspend blockers, then sure, but its a long way away from the explicit scheme proposed at the start of this thread. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 2, 2010 at 9:24 PM, Paul Mundt wrote: > > On the other hand, while this isn't that difficult for the UP case it > does pose more problems for the SMP case. Presently the suspend paths > (suspend-to-RAM/hibernate/kexec jump) all deal with disabling and > enabling of non-boot CPUs via CPU hotplug explicitly, which will clear > them from the online CPU map. We would have to rework the semantics a bit > if cpuidle were also permitted to opportunistically offline CPUs. That's definitely something we'd be interested in looking at. Some upcoming ARM v7 architecture SMP SoCs we're seeing will support full independent clock scaling and power gating for the individual cores -- if there's not enough work to keep the 2nd (or nth) cpu busy, there would be good power savings to be had shutting it down. I haven't poked around too much with how things work in SMP environments -- are there per-cpu idle threads? 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 2, 2010 at 11:33 PM, Neil Brown wrote: >> >> The current suspend-blocker proposal already involves userspace >> changes (it's different than our existing wakelock interface), and >> we're certainly not opposed to any/all userspace changes on principle, >> but on the other hand we're not interested in significant reworks of >> userspace unless they actually improve the situation somehow. I think >> bottlenecking events through a central daemon would represent a step >> backwards. > > I guess it becomes an question of economics for you then. Does the cost of > whatever user-space changes are required exceed the value of using an upstream > kernel? Both the cost and the value would be very hard to estimate in > advance. I don't envy you the decision... Well, at this point we've invested more engineering hours in the various rewrites of this (single) patchset and discussion around it than we have spent on rebasing our trees on roughly every other mainline release since 2.6.16 or so, across five years of Android development. We think there's some good value to be had (all the usual reasons) by heading upstream, so we're still discussing these patches and exploring alternatives, but yes, from one way of looking at it, it'd certainly be cheaper to just keep maintaining our own trees. 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 11:05:18 -0700 Brian Swetland wrote: > On Wed, Jun 2, 2010 at 1:06 AM, Neil Brown wrote: > > On Wed, 2 Jun 2010 00:05:14 -0700 > > Arve Hjønnevåg wrote: > >> > The user-space suspend daemon avoids losing wake-events by using > >> > fcntl(F_OWNER) to ensure it gets a signal whenever any important > >> > wake-event > >> > is ready to be read by user-space. This may involve: > >> > - the one daemon processing all wake events > >> > >> Wake up events are not all processed by one daemon. > > > > Not with your current user-space code, no. Are you saying that you are not > > open to any significant change in the Android user-space code? That would > > make the situation a lot harder to resolve. > > There are many wakeup events possible in a typical system -- > keypresses or other input events, network traffic, telephony events, > media events (fill audio buffer, fill video decoder buffer, etc), and > I think requiring that all wakeup event processing bottleneck through > a single userspace process is non-optimal here. Just to be clear: I'm not suggesting all wake-events need to go through one process. That was just one example of how the interface I proposed could be used. There were two other examples. However one process would need to know about any wakeup event that happens. I don't think that needs to be a significant bottleneck, but I don't really know enough about all the requirement to try devising a demonstration. > > The current suspend-blocker proposal already involves userspace > changes (it's different than our existing wakelock interface), and > we're certainly not opposed to any/all userspace changes on principle, > but on the other hand we're not interested in significant reworks of > userspace unless they actually improve the situation somehow. I think > bottlenecking events through a central daemon would represent a step > backwards. I guess it becomes an question of economics for you then. Does the cost of whatever user-space changes are required exceed the value of using an upstream kernel? Both the cost and the value would be very hard to estimate in advance. I don't envy you the decision... NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH] - race-free suspend. Was: Re: [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 2, 2010 at 11:04 PM, mark gross <640e9...@gmail.com> wrote: >> >> There are many wakeup events possible in a typical system -- >> keypresses or other input events, network traffic, telephony events, >> media events (fill audio buffer, fill video decoder buffer, etc), and >> I think requiring that all wakeup event processing bottleneck through >> a single userspace process is non-optimal here. > > Um doesn't the android framework bottleneck the user mode lock > processing through the powermanager and any wake up event processing > eventually has to grab a lock through this bottleneck anyway? For "high level" framework/application level wakelocks, yes, but lower level components beneath the java api layer use the kernel interface directly. 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] [PATCH] - race-free suspend. Was: Re: [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 02, 2010 at 11:05:18AM -0700, Brian Swetland wrote: > On Wed, Jun 2, 2010 at 1:06 AM, Neil Brown wrote: > > On Wed, 2 Jun 2010 00:05:14 -0700 > > Arve Hjønnevåg wrote: > >> > The user-space suspend daemon avoids losing wake-events by using > >> > fcntl(F_OWNER) to ensure it gets a signal whenever any important > >> > wake-event > >> > is ready to be read by user-space. This may involve: > >> > - the one daemon processing all wake events > >> > >> Wake up events are not all processed by one daemon. > > > > Not with your current user-space code, no. Are you saying that you are not > > open to any significant change in the Android user-space code? That would > > make the situation a lot harder to resolve. > > There are many wakeup events possible in a typical system -- > keypresses or other input events, network traffic, telephony events, > media events (fill audio buffer, fill video decoder buffer, etc), and > I think requiring that all wakeup event processing bottleneck through > a single userspace process is non-optimal here. Um doesn't the android framework bottleneck the user mode lock processing through the powermanager and any wake up event processing eventually has to grab a lock through this bottleneck anyway? > > The current suspend-blocker proposal already involves userspace > changes (it's different than our existing wakelock interface), and > we're certainly not opposed to any/all userspace changes on principle, > but on the other hand we're not interested in significant reworks of > userspace unless they actually improve the situation somehow. I think > bottlenecking events through a central daemon would represent a step > backwards. I'm not sure its a step in any direction, but I do understand the avoidance of having to rework a lot of code. --mgross -- 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] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 06:06:43PM +0200, Thomas Gleixner wrote: > On Thu, 27 May 2010, Alan Stern wrote: > > And to answer Thomas's question: The whole reason for having in-kernel > > suspend blockers is so that userspace can tell the system to suspend > > without losing wakeup events. > > > > Suppose a key is pressed just as a user program writes "mem" to > > /sys/power/state. The keyboard driver handles the keystroke and queues > > an input event. Then the system suspends and doesn't wake up until > > some other event occurs -- even though the keypress was an important > > one and it should have prevented the system from suspending. > > > > With in-kernel suspend blockers and opportunistic suspend, this > > scenario is prevented. That is their raison-d'etre. > > I tend to disagree. You are still looking at suspend as some extra > esoteric mechanism. We should stop doing this and look at suspend (to > RAM) as an additional deep idle state, which is well defined in terms > of power savings and wakeup latency. That's what I think opportunistic > suspend is all about. Now if you look at our current idle states in > x86 the incoming keystroke is never lost. > For systems with runtime PM and deep idle states in cpuidle suspend is already fairly opportunistic. If sleep states (including suspend to RAM and CPU off) are factored in to cpuidle then it's very easy to get in to situations where everything simply shuts off automatically, which can be problematic if a platform doesn't expose any external wakeup sources. Platforms still need to be able to establish some heuristics, whether this is via blocking certain state transitions or simply defining a maximum acceptable suspend depth irrespective of latency (at least we presently don't have a clean interface for preventing entry in to impossible to recover from idle states outside of latency hints via PM QoS, or at least not one that I'm aware of). On the other hand, while this isn't that difficult for the UP case it does pose more problems for the SMP case. Presently the suspend paths (suspend-to-RAM/hibernate/kexec jump) all deal with disabling and enabling of non-boot CPUs via CPU hotplug explicitly, which will clear them from the online CPU map. We would have to rework the semantics a bit if cpuidle were also permitted to opportunistically offline CPUs. -- 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 19:44:59 -0700 Arve Hjønnevåg wrote: > On Wed, Jun 2, 2010 at 4:32 PM, Dmitry Torokhov > wrote: > > On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote: > >> On Wed, 2 Jun 2010 21:02:24 +1000 > >> Neil Brown wrote: > >> > > >> > And this decision (to block suspend) really needs to be made in the > >> > driver, > >> > not in userspace? > >> > >> Well, it fits. The requirement is a direct consequence of the intimate > >> knowledge the driver has about the driven devices. > > > > That is not really true. A driver does have intimate knowledge of the > > device, however it does not necessarily have an idea about the data read > > from the device. Consider the gpio_matrix driver: Arve says that it has > > to continue scanning matrix once first interrupt arrvies. But it really > > depends on what key has been pressed - if user pressed KEY_SUSPEND or > > KEY_POWER it cmight be better if we did not wait for key release but > > initiated the action right away. The decision on how system reacts to a > > key press does not belong to the driver but really to userspace. > > If we just suspend while the keypad scan is active, a second press of > KEY_POWER would not be able wake the device up. The gpio keypad matrix > driver has two operating modes. No keys are pressed: all the outputs > are active so a key press will generate an interrupt in one of the > inputs. Keys are pressed: Activate a single output at a time so we can > determine which keys are pressed. The second mode is entered when the > driver gets an interrupt in the first mode. The first mode is entered > if the scan detected that no keys are pressed. The driver could be > modified to stop the scan on suspend and forcibly put the device back > in no-keys-pressed state, but pressing additional keys connected to > the same input can no longer generate any events (the input does not > change). > Thanks for the detailed explanation. That helps a lot. I see that if follows that performing a suspend while keys are pressed would not be good, and keys could be pressed for arbitrarily long periods. It does not follow that the keypad driver should therefore explicitly disable suspend. It could simply inform user-space that the keypad is in the alternate scan mode, so user-space can choose not to enter suspend in at that time (i.e. policy in user-space). I can see also how one might want to express this behaviour as a PM_QOS constraint (now that I have read a bit about PM_QOS), but I cannot see that you would need to. As the keypad driver is polling during this mode, it would presumably set a timer that would fire in the near future, and the very existence of this timer (with a duration shorter than the S3 latency) would be enough to ensure S3 wasn't automatically entered by PM. At most you might use set_timer_slack to give a slightly higher upper bound to the timeout. So if we take the suspend-from-idle approach, this driver needs no annotation, and if we take the 'fix the suspend/wake-event race' then this driver needs no special treatment - just enough to close the race, and some user-space policy support. i.e. it doesn't seem to be a special case. 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 2, 2010 at 4:32 PM, Dmitry Torokhov wrote: > On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote: >> On Wed, 2 Jun 2010 21:02:24 +1000 >> Neil Brown wrote: >> > >> > And this decision (to block suspend) really needs to be made in the driver, >> > not in userspace? >> >> Well, it fits. The requirement is a direct consequence of the intimate >> knowledge the driver has about the driven devices. > > That is not really true. A driver does have intimate knowledge of the > device, however it does not necessarily have an idea about the data read > from the device. Consider the gpio_matrix driver: Arve says that it has > to continue scanning matrix once first interrupt arrvies. But it really > depends on what key has been pressed - if user pressed KEY_SUSPEND or > KEY_POWER it cmight be better if we did not wait for key release but > initiated the action right away. The decision on how system reacts to a > key press does not belong to the driver but really to userspace. If we just suspend while the keypad scan is active, a second press of KEY_POWER would not be able wake the device up. The gpio keypad matrix driver has two operating modes. No keys are pressed: all the outputs are active so a key press will generate an interrupt in one of the inputs. Keys are pressed: Activate a single output at a time so we can determine which keys are pressed. The second mode is entered when the driver gets an interrupt in the first mode. The first mode is entered if the scan detected that no keys are pressed. The driver could be modified to stop the scan on suspend and forcibly put the device back in no-keys-pressed state, but pressing additional keys connected to the same input can no longer generate any events (the input does not change). -- 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 16:32:44 -0700 Dmitry Torokhov wrote: > On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote: > > On Wed, 2 Jun 2010 21:02:24 +1000 > > Neil Brown wrote: > > > > > > And this decision (to block suspend) really needs to be made in the > > > driver, > > > not in userspace? > > > > Well, it fits. The requirement is a direct consequence of the intimate > > knowledge the driver has about the driven devices. > > That is not really true. A driver does have intimate knowledge of the > device, however it does not necessarily have an idea about the data read > from the device. Consider the gpio_matrix driver: Arve says that it has > to continue scanning matrix once first interrupt arrvies. But it really > depends on what key has been pressed - if user pressed KEY_SUSPEND or > KEY_POWER it cmight be better if we did not wait for key release but > initiated the action right away. The decision on how system reacts to a > key press does not belong to the driver but really to userspace. > I can't follow the gpio_matrix_driver example, but your point is obviously true. A device should never register a constraint because of the data it handles. That belongs into userspace. Or wherever the data is consumed. I'm obviously not trying to say that a network driver should block suspend while I'm on facebook. Or unblock when visiting m$.com. That would be absurd. But, there are of course places in the kernel, where some kernel code listens to data. For example the packet-filtering. Or sysrq-keys. But I don't know how that relates to suspend_blockers now... ? Mind if I rephrase the quote? From: "Well, it fits. The requirement is a direct consequence of the intimate knowledge the driver has about the driven devices." To: "It fits, when the requirement is a direct consequence of the intimate knowledge the driver has about the driven devices." Cheers, Flo p.s.: tsss language... what a broken concept. And yet we have to work with it. -- 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote: > On Wed, 2 Jun 2010 21:02:24 +1000 > Neil Brown wrote: > > > > And this decision (to block suspend) really needs to be made in the driver, > > not in userspace? > > Well, it fits. The requirement is a direct consequence of the intimate > knowledge the driver has about the driven devices. That is not really true. A driver does have intimate knowledge of the device, however it does not necessarily have an idea about the data read from the device. Consider the gpio_matrix driver: Arve says that it has to continue scanning matrix once first interrupt arrvies. But it really depends on what key has been pressed - if user pressed KEY_SUSPEND or KEY_POWER it cmight be better if we did not wait for key release but initiated the action right away. The decision on how system reacts to a key press does not belong to the driver but really to userspace. -- Dmitry -- 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 21:05:21 +0200 Florian Mickler wrote: > Could someone perhaps make a recap on what are the problems with the > API? I have no clear eye (experience?) for that (or so it seems). Good interface design is an acquired taste. And it isn't always easy to explain satisfactorily. But let me try to explain what I see. A key aspect of a good interface is unity, and sometimes uniformity. For example, the file descriptor is a key element to the unity of the Unix (and hence Posix and Linux) interface. "everything is a file" and even when it isn't, everything is accessed via a file descriptor. This is one of the reasons that signals cause so much problem when programming in Unix - they aren't files, don't have file descriptors and don't look them at all. That is why signalfd was created, to try to tie signals back in to the 'file descriptor' model. So unity is important. Adding new concepts is best done as an extension of an existing concept. That means that all the infrastructure, not only code and design but also developer understanding, can be leveraged to help get the new concept *right* first time. It also means that using the new concept is easier to learn. So the problem with the wake-locks / suspend-blockers (and I've actually come to like the first name much more) is that it introduces a new concept without properly leveraging existing concepts. The new concept is opportunistic suspend, though maybe a better name would be automatic suspend - not sure. There appear to be two ways you can get opportunistic suspend leveraging already-existing concepts. One is to leverage the current "power/state = mem" architecture and just let userspace choose the opportune moment. The user-space daemon that chooses this moment would need full information about states of various things to do this, but sysfs is good at providing full information about what is in the kernel, and there are dozens of ways for user-space processes to communicate their state to each other. So this is all doable today without introducing new design concepts. Except there is a race between suspending and new events, so we just need to fix the race. Hence my patch. The other is to leverage the more general power management infrastructure. We can already detect when the processor won't be needed for a while, and put it into a low-power state. We can already put devices to sleep when they aren't being used. We can just generalise this so that we can detect when all devices are either unused, or capable of supporting an S3 transition, and detect when the next timer interrupt is far enough in the future that S3 latency wont be a problem - set the rtc alarm to match the next timer and go to S3. All completely transparent. (I admit I'm not entirely sure what the qos that is being discussed brings us, but I assume it is better quality rather than correctness). So there are at least two different ways that opportunistic suspend could be integrated into existing infrastructure with virtually no change of interface and no new concepts - just refining or extending existing concepts. Yet the approach used and preferred by android is to create something substantially new. Yes, it does use the existing suspend infrastructure, but in a very new and different way. Suspend is now initiated by the kernel, but in a completely different way to the ways that the kernel already initiates power saving. So we have two infrastructures for essentially one task. Looked at the other way, it moves the initiation of suspend from user-space into the kernel, and then allows user-space to tell the kernel not to suspend. That to me is very ugly. In general, the kernel should provide information to user-space, and provide services to user-space, and user-space should use that information to decide what services to request. This is the essence the "policy lives in user-space" maxim. The Android code has user-space giving information to the kernel, so the kernel can make a policy decision. This approach is generally less flexible and is best avoided. Just as a bit of background, let's think about some of the areas in the kernel where the kernel does make policy decisions based on user-space input. - the scheduler - based on 'nice' setting it decided who should run when - the VM - based on read-ahead settings, madvise/fadvise, recent-use heuristics, it tries to decide what to keep in memory and what to swap out. I think those are the main ones. There are other smaller fish like the choice of IO scheduler and various ways to tune network connections. But the two big ones are perfect examples of subsystems that have proven very hard to get *right*, and have been substantially re-written more than once. In each case, the difficulty wasn't how to perform the work, it was the choice of what work to perform. It probably also involved getting different sorts of information about the current state. That perspective leaves me very sceptical
RE: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
>-Original Message- >From: Florian Mickler [mailto:flor...@mickler.org] >Sent: Wednesday, June 02, 2010 4:06 PM >To: James Bottomley >Cc: Arve Hjønnevåg; Neil Brown; ty...@mit.edu; Peter Zijlstra; LKML; Alan >Cox; Gross, Mark; Thomas Gleixner; Linux OMAP Mailing List; Linux PM; >felipe.ba...@nokia.com >Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) > >On Wed, 02 Jun 2010 15:41:11 -0500 >James Bottomley wrote: > >> On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote: >> > On Wed, 02 Jun 2010 10:05:11 -0500 >> > James Bottomley wrote: >> > >> > > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: >> > > > No, they have to be two separate constraints, otherwise a >constraint >> > > > to block suspend would override a constraint to block a low power >idle >> > > > mode or the other way around. >> > > >> > > Depends. If you block the system from going into low power idle, >does >> > > that mean you still want it to be fully suspended? >> > > >> > > If yes, then we do have independent constraints. If not, they have a >> > > hierarchy: >> > > >> > > * Fully Interactive (no low power idle or suspend) >> > > * Partially Interactive (may go into low power idle but not >> > > suspend) >> > > * None (may go into low power idle or suspend) >> > > >> > > Which is expressable as a ternary constraint. >> > > >> > > James >> > > >> > >> > But unblocking suspend at the moment is independent to getting idle. >> > If you have the requirement to stay in the highest-idle level (i.e. >> > best latency you can get) that does not (currently) mean, that you can >> > not suspend. >> >> I don't understand that as a reason. If we looks at this a qos >> constraints, you're saying that the system may not drop into certain low >> power states because it might turn something off that's currently being >> used by a driver or a process. Suspend is certainly the lowest state of >> that because it turns everything off, why would it be legal to drop into >> that? >> >> I also couldn't find this notion of separation of idleness power from >> suspend blocking in the original suspend block patch set ... if you can >> either tell me where it is, or give me an example of the separated use >> cases, I'd understand better. >> >> > To preserve that explicit fall-through while still having working >> > run-time-powermanagement I think the qos-constraints need to be >> > separated. >> >> OK, as above, why? or better yet, just give an example. > >Hm. Maybe it is me who doesn't understand. > >With proposed patchset: >1. As soon as we unblock suspend we go down. (i.e. suspending) >2. While suspend is blocked, the idle-loop does it's things. (i.e. >runtime power managment -> can give same power-result as suspend) > >possible cases: >1: > - qos-latency-constraints: 1ms, [here: forbids anything other than > C1 idle state.] > - suspend is blocked > >2: - qos latency-constraints: as in 1 > - suspend unblocked > >3: - qos latency-constraints: infinity, cpu in lowest power state. > - suspend is blocked > >4: - qos latency-constraints: infinity, cpu in lowest power state. > - suspend unblocked > > >in case 2 and 4 we would suspend, regardeless of the qos-latency. > >in case 1 and 3 we would stay awake, regardeless of the qos-latency >constraint. > > >If only one constraint, then case 2 (or 3) wouldn't be possible. But it >is possible now. > >A possible use case as an example? >(hmm... i'm trying my imagination hard now): > Your sound needs low latency, so that could be a cause for the > qos-latency constraint. > > And unblocking suspend could nonetheless happen: > For example... you have an firefox open and don't want to > prevent suspend for that case when the display is turned off > > [mtg: ] This has been a pain point for the PM_QOS implementation. They change the constrain back and forth at the transaction level of the i2c driver. The pm_qos code really wasn't made to deal with such hot path use, as each such change triggers a re-computation of what the aggregate qos request is. We've had a number of attempts at fixing this, but I think the proper fix is to bolt a "disable C-states > x" interface into cpu_idle that bypases pm_qos altogether. Or, perhaps add a new pm_qos API that does the equivalent operation, overriding whatever constraint is active. --mgross -- 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] [PATCH 0/8] Suspend block api (version 8)
On Wed, 02 Jun 2010 15:41:11 -0500 James Bottomley wrote: > On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote: > > On Wed, 02 Jun 2010 10:05:11 -0500 > > James Bottomley wrote: > > > > > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: > > > > No, they have to be two separate constraints, otherwise a constraint > > > > to block suspend would override a constraint to block a low power idle > > > > mode or the other way around. > > > > > > Depends. If you block the system from going into low power idle, does > > > that mean you still want it to be fully suspended? > > > > > > If yes, then we do have independent constraints. If not, they have a > > > hierarchy: > > > > > > * Fully Interactive (no low power idle or suspend) > > > * Partially Interactive (may go into low power idle but not > > > suspend) > > > * None (may go into low power idle or suspend) > > > > > > Which is expressable as a ternary constraint. > > > > > > James > > > > > > > But unblocking suspend at the moment is independent to getting idle. > > If you have the requirement to stay in the highest-idle level (i.e. > > best latency you can get) that does not (currently) mean, that you can > > not suspend. > > I don't understand that as a reason. If we looks at this a qos > constraints, you're saying that the system may not drop into certain low > power states because it might turn something off that's currently being > used by a driver or a process. Suspend is certainly the lowest state of > that because it turns everything off, why would it be legal to drop into > that? > > I also couldn't find this notion of separation of idleness power from > suspend blocking in the original suspend block patch set ... if you can > either tell me where it is, or give me an example of the separated use > cases, I'd understand better. > > > To preserve that explicit fall-through while still having working > > run-time-powermanagement I think the qos-constraints need to be > > separated. > > OK, as above, why? or better yet, just give an example. Hm. Maybe it is me who doesn't understand. With proposed patchset: 1. As soon as we unblock suspend we go down. (i.e. suspending) 2. While suspend is blocked, the idle-loop does it's things. (i.e. runtime power managment -> can give same power-result as suspend) possible cases: 1: - qos-latency-constraints: 1ms, [here: forbids anything other than C1 idle state.] - suspend is blocked 2: - qos latency-constraints: as in 1 - suspend unblocked 3: - qos latency-constraints: infinity, cpu in lowest power state. - suspend is blocked 4: - qos latency-constraints: infinity, cpu in lowest power state. - suspend unblocked in case 2 and 4 we would suspend, regardeless of the qos-latency. in case 1 and 3 we would stay awake, regardeless of the qos-latency constraint. If only one constraint, then case 2 (or 3) wouldn't be possible. But it is possible now. A possible use case as an example? (hmm... i'm trying my imagination hard now): Your sound needs low latency, so that could be a cause for the qos-latency constraint. And unblocking suspend could nonetheless happen: For example... you have an firefox open and don't want to prevent suspend for that case when the display is turned off 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] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-06-02 at 15:27 -0700, Arve Hjønnevåg wrote: > On Wed, Jun 2, 2010 at 1:41 PM, James Bottomley > wrote: > > On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote: > >> On Wed, 02 Jun 2010 10:05:11 -0500 > >> James Bottomley wrote: > >> > >> > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: > >> > > No, they have to be two separate constraints, otherwise a constraint > >> > > to block suspend would override a constraint to block a low power idle > >> > > mode or the other way around. > >> > > >> > Depends. If you block the system from going into low power idle, does > >> > that mean you still want it to be fully suspended? > >> > > >> > If yes, then we do have independent constraints. If not, they have a > >> > hierarchy: > >> > > >> > * Fully Interactive (no low power idle or suspend) > >> > * Partially Interactive (may go into low power idle but not > >> > suspend) > >> > * None (may go into low power idle or suspend) > >> > > >> > Which is expressable as a ternary constraint. > >> > > >> > James > >> > > >> > >> But unblocking suspend at the moment is independent to getting idle. > >> If you have the requirement to stay in the highest-idle level (i.e. > >> best latency you can get) that does not (currently) mean, that you can > >> not suspend. > > > > I don't understand that as a reason. If we looks at this a qos > > constraints, you're saying that the system may not drop into certain low > > power states because it might turn something off that's currently being > > used by a driver or a process. Suspend is certainly the lowest state of > > that because it turns everything off, why would it be legal to drop into > > that? > > Because the driver gets called on suspend which gives it a change to > stop using it. > > > > > I also couldn't find this notion of separation of idleness power from > > suspend blocking in the original suspend block patch set ... if you can > > either tell me where it is, or give me an example of the separated use > > cases, I'd understand better. > > > > The suspend block patchset only deals with suspend, not low power idle > modes. The original wakelock patchset had two wakelock types, idle and > suspend. OK, so that explains why I didn't see it ... > >> To preserve that explicit fall-through while still having working > >> run-time-powermanagement I think the qos-constraints need to be > >> separated. > > > > OK, as above, why? or better yet, just give an example. > > > > The i2c bus on the Nexus One is used by the other core to turn off the > power you our core when we enter the lowest power mode. This means > that we cannot enter that low power mode while the i2c bus is active, > so we block low power idle modes. At some point we also tries to block > suspend in this case, but this caused a lot of failed suspend attempts > since the frequency scaling code would try to ramp up while freezing > processes which in turn aborted the process freezing attempts. OK, so this is a device specific power constraint state. I suppose it makes sense to have a bunch of those, because the device isn't necessarily going to know what idle power mode it can't go into, so the cpu govenor should sort it out rather than have the device specify a minimum state. 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] [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 2, 2010 at 1:41 PM, James Bottomley wrote: > On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote: >> On Wed, 02 Jun 2010 10:05:11 -0500 >> James Bottomley wrote: >> >> > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: >> > > No, they have to be two separate constraints, otherwise a constraint >> > > to block suspend would override a constraint to block a low power idle >> > > mode or the other way around. >> > >> > Depends. If you block the system from going into low power idle, does >> > that mean you still want it to be fully suspended? >> > >> > If yes, then we do have independent constraints. If not, they have a >> > hierarchy: >> > >> > * Fully Interactive (no low power idle or suspend) >> > * Partially Interactive (may go into low power idle but not >> > suspend) >> > * None (may go into low power idle or suspend) >> > >> > Which is expressable as a ternary constraint. >> > >> > James >> > >> >> But unblocking suspend at the moment is independent to getting idle. >> If you have the requirement to stay in the highest-idle level (i.e. >> best latency you can get) that does not (currently) mean, that you can >> not suspend. > > I don't understand that as a reason. If we looks at this a qos > constraints, you're saying that the system may not drop into certain low > power states because it might turn something off that's currently being > used by a driver or a process. Suspend is certainly the lowest state of > that because it turns everything off, why would it be legal to drop into > that? Because the driver gets called on suspend which gives it a change to stop using it. > > I also couldn't find this notion of separation of idleness power from > suspend blocking in the original suspend block patch set ... if you can > either tell me where it is, or give me an example of the separated use > cases, I'd understand better. > The suspend block patchset only deals with suspend, not low power idle modes. The original wakelock patchset had two wakelock types, idle and suspend. >> To preserve that explicit fall-through while still having working >> run-time-powermanagement I think the qos-constraints need to be >> separated. > > OK, as above, why? or better yet, just give an example. > The i2c bus on the Nexus One is used by the other core to turn off the power you our core when we enter the lowest power mode. This means that we cannot enter that low power mode while the i2c bus is active, so we block low power idle modes. At some point we also tries to block suspend in this case, but this caused a lot of failed suspend attempts since the frequency scaling code would try to ramp up while freezing processes which in turn aborted the process freezing attempts. >> >> Provided you can reach the same power state from idle, current suspend >> could probably also be implemented by just the freezing part and a hint >> to the idle-loop to provide accelerated fall-through to lowest power. >> >> >> At that point, you could probably merge the constraints. >> >> But the freezing part is also the hard part, isn't it? (I have no >> idea. Thomas seems to think about cgroups for that and doing smth about the >> timers.) > > Um, well, as I said, I think using suspend from idle and freezer is > longer term. I think if we express the constraints as qos android can > then use them to gate when to enter S3 .. which is functionally > equivalent to suspend blockers. And the vanilla kernel can use them to > gate power states for the drivers in suspend from idle. > > James > > > -- 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thursday 03 June 2010, Neil Brown wrote: > On Wed, 2 Jun 2010 22:41:14 +0200 > "Rafael J. Wysocki" wrote: > > > On Wednesday 02 June 2010, Neil Brown wrote: > > > - Would this fix the "bug"?? > > > - and address the issues that suspend-blockers was created to address? > > > - or are the requirements on user-space too onerous? > > > > In theory wakeup events can also happen after wait_for_blockers() has > > returned > > 0 and I guess we should rollback the suspend in such cases. > > > > I naively assumed this was already the case, but on a slightly closer look at > the code it seems not. > > Presumably there is some point deep in the suspend code, probably after the > call to sysdev_suspend, where interrupts are disabled and we are about to > actually suspend. At that point a simple "is a roll-back required" test > could abort the suspend. Yes. > Then any driver that handles wake-up events, if it gets and event that (would > normally cause a wakeup) PM_SUSPEND_PREPARE and PM_POST_SUSPEND, could set > the "roll-back is required" flag. That's my idea, but instead of setting a flag, I'd use a counter increased every time there is a wakeup event. Then, the core suspend core code would store a pre-suspend value of the counter and compare it with the current value after all wakeup event sources had been set. If they were different, the suspend would be aborted. 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 22:41:14 +0200 "Rafael J. Wysocki" wrote: > On Wednesday 02 June 2010, Neil Brown wrote: > > - Would this fix the "bug"?? > > - and address the issues that suspend-blockers was created to address? > > - or are the requirements on user-space too onerous? > > In theory wakeup events can also happen after wait_for_blockers() has > returned > 0 and I guess we should rollback the suspend in such cases. > I naively assumed this was already the case, but on a slightly closer look at the code it seems not. Presumably there is some point deep in the suspend code, probably after the call to sysdev_suspend, where interrupts are disabled and we are about to actually suspend. At that point a simple "is a roll-back required" test could abort the suspend. Then any driver that handles wake-up events, if it gets and event that (would normally cause a wakeup) PM_SUSPEND_PREPARE and PM_POST_SUSPEND, could set the "roll-back is required" flag. ?? NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wednesday 02 June 2010, Neil Brown wrote: > On Tue, 1 Jun 2010 10:47:49 -0400 (EDT) > Alan Stern wrote: ... > So yes, there are different use cases and we should support all of them, > both "I shut the lid and my laptop really stays asleep" and "I never miss a > TXT because my phone went to sleep at a bad time". The process that > initiates the suspend has a role in choosing what can wake it up. You'd need to add some all new infrastructure for that, because right now only hardware wakeup signals are regarded as (system) wakeup events (they are either interrupts or things like PCI PMEs, possibly translated to some platform signals like GPIOs or something). I think I know how to prevent these hardware wakeup events from being lost (such that the entire suspend will be aborted if one of them happens during suspend), but for the handling of more generally defined wakeup events we'd need to provide user space with information on what wakeup events are available and how to enable and disable them, among other things. 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wednesday 02 June 2010, Neil Brown wrote: > On Tue, 1 Jun 2010 12:50:01 +0200 (CEST) > Thomas Gleixner wrote: > > > On Tue, 1 Jun 2010, Neil Brown wrote: > > > > > > I think you have acknowledged that there is a race with suspend - thanks. > > > Next step was "can it be closed". > > > You seem to suggest that it can, but you describe it as a "work around" > > > rather than a "bug fix"... > > > > > > Do you agree that the race is a "bug", and therefore it is appropriate to > > > "fix" it assuming an acceptable fix can be found (which I think it can)? > > > > If we can fix it, yes we definitely should do and not work around it. > > > > Thanks, > > > > tglx > > OK. > Here is my suggestion. > > While I think this patch would actually work, and hope the ugly aspects are > reasonably balanced by the simplicity, I present it primarily as a base for > improvement. > The important part is to present how drivers and user-space can co-operate > to avoid losing wake-events. The details of what happens in the kernel are > certainly up for discussion (as is everything else really of course). > > The user-space suspend daemon avoids losing wake-events by using > fcntl(F_OWNER) to ensure it gets a signal whenever any important wake-event > is ready to be read by user-space. This may involve: > - the one daemon processing all wake events > - Both the suspend daemon and the main event handling daemon opening any > given device that delivers wake events (this should work with input > events ... unless grabbing is needed) > - The event handling daemon giving the suspend-daemon's pid as F_OWNER, and > using poll/select to get the events itself. > > When 'mem' is written to /sys/power/state, suspend_prepare waits in an > interruptible wait until any wake-event that might have been initiated before > the suspend was request, has had a chance to be queued for user-space and > trigger kill_fasync. > Currently this wait is a configurable time after the last wake-event was > initiated. This is hackish, but simple and probably adequate. > If more precise timing is needed and achievable, that can be added later. It > would be an entirely internal change and would not affect the API further. > Some of the code developed for suspend-blockers might be a starting point for > this. > > Drivers should call pm_suspend_delay() whenever a wake-event occurs. This > simply records the time so that the suspend process knows if there is in fact > any need to wait at all. > > The delay to wait after the last pm_suspend_delay() is limited to 10 seconds > and can be set by kernel parameter suspend_block_delay=number-of-milliseconds > It defaults to 2 jiffies (which is possibly too short). > > - Would this fix the "bug"?? > - and address the issues that suspend-blockers was created to address? > - or are the requirements on user-space too onerous? In theory wakeup events can also happen after wait_for_blockers() has returned 0 and I guess we should rollback the suspend in such cases. 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] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote: > On Wed, 02 Jun 2010 10:05:11 -0500 > James Bottomley wrote: > > > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: > > > No, they have to be two separate constraints, otherwise a constraint > > > to block suspend would override a constraint to block a low power idle > > > mode or the other way around. > > > > Depends. If you block the system from going into low power idle, does > > that mean you still want it to be fully suspended? > > > > If yes, then we do have independent constraints. If not, they have a > > hierarchy: > > > > * Fully Interactive (no low power idle or suspend) > > * Partially Interactive (may go into low power idle but not > > suspend) > > * None (may go into low power idle or suspend) > > > > Which is expressable as a ternary constraint. > > > > James > > > > But unblocking suspend at the moment is independent to getting idle. > If you have the requirement to stay in the highest-idle level (i.e. > best latency you can get) that does not (currently) mean, that you can > not suspend. I don't understand that as a reason. If we looks at this a qos constraints, you're saying that the system may not drop into certain low power states because it might turn something off that's currently being used by a driver or a process. Suspend is certainly the lowest state of that because it turns everything off, why would it be legal to drop into that? I also couldn't find this notion of separation of idleness power from suspend blocking in the original suspend block patch set ... if you can either tell me where it is, or give me an example of the separated use cases, I'd understand better. > To preserve that explicit fall-through while still having working > run-time-powermanagement I think the qos-constraints need to be > separated. OK, as above, why? or better yet, just give an example. > > Provided you can reach the same power state from idle, current suspend > could probably also be implemented by just the freezing part and a hint > to the idle-loop to provide accelerated fall-through to lowest power. > > > At that point, you could probably merge the constraints. > > But the freezing part is also the hard part, isn't it? (I have no > idea. Thomas seems to think about cgroups for that and doing smth about the > timers.) Um, well, as I said, I think using suspend from idle and freezer is longer term. I think if we express the constraints as qos android can then use them to gate when to enter S3 .. which is functionally equivalent to suspend blockers. And the vanilla kernel can use them to gate power states for the drivers in suspend from idle. 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] [PATCH 0/8] Suspend block api (version 8)
On Wed, 02 Jun 2010 12:21:28 +0200 Peter Zijlstra wrote: > On Wed, 2010-06-02 at 03:00 -0700, Arve Hjønnevåg wrote: > > 2010/6/2 Peter Zijlstra : > > > On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote: > > >> No I want you to stop confusing low power idle modes with suspend. > > > > > > I think it is you who is confused. For power management purposes suspend > > > is nothing more but a deep idle state. > > > > No, idle is transparent, suspend is not. > > Which is where the problem is, it should be. > > > Why would I add suspend blockers to the code I want to prevent running? > > Because what you want might not be what others want. Suppose you're fine > with your torrent client/irc client/etc.. to loose their network > connection when you're not behind your desktop so you don't add suspend > blockers there. > > Me, I'd be ready to administer physical violence if either of those lost > their connections when I wasn't around to keep the screen-saver from > kicking in. Do you switch your pc on and off manually? Sometimes? Really? (if not, you are probably a kernel hacker *g*) I assume, in general, there are only a few reasons to shut down a machine: 1. One has to do maintainance on the hardware or somehow needs to interrupt the power supply. 2. One wants to save power. 3. One wants to go easy on the hardware. 4. ...? Obviously, for reason 1 we need to maintain the shutdown-paths indefinitely. But the rest are usecases that are similar to the suspend-blocker usecases. You know that you are not using the machine and going through the pain to shut down your machine. You have to do it manually. Why? > This leads to having to sprinkle magic dust (and lots of config options) > all over userspace. Something that gets esp interesting with only a > boolean interface. A userspace daemon could keep track of what applications can be ignored. The wordprocessor probably should not keep the system busy. As well as a running firefox. It is a hard problem. But we have _no way of deciding any of this in the kernel_! > > In the example above, having an active net connection would prevent my > desktop from suspending, but what if another platform can maintain net > connections while suspended? Do we then end up with arch specific code > in the net-stack? I'm sure DaveM would love that. > If it is driver knowledge, then it goes into the driver. If it is platform knowledge, then it goes into the platform code. I think that is a clear requirement to keeping sanity. The problem is there independently of suspend blockers. If the system can suspend with network up, then you shure as hell want to suspend even if the network is up. So it would actually be a reason for any kind of "suspend blockers" scheme. Wouldn't it? 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] [PATCH 0/8] Suspend block api (version 8)
On Wed, 02 Jun 2010 10:05:11 -0500 James Bottomley wrote: > On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: > > No, they have to be two separate constraints, otherwise a constraint > > to block suspend would override a constraint to block a low power idle > > mode or the other way around. > > Depends. If you block the system from going into low power idle, does > that mean you still want it to be fully suspended? > > If yes, then we do have independent constraints. If not, they have a > hierarchy: > > * Fully Interactive (no low power idle or suspend) > * Partially Interactive (may go into low power idle but not > suspend) > * None (may go into low power idle or suspend) > > Which is expressable as a ternary constraint. > > James > But unblocking suspend at the moment is independent to getting idle. If you have the requirement to stay in the highest-idle level (i.e. best latency you can get) that does not (currently) mean, that you can not suspend. To preserve that explicit fall-through while still having working run-time-powermanagement I think the qos-constraints need to be separated. Provided you can reach the same power state from idle, current suspend could probably also be implemented by just the freezing part and a hint to the idle-loop to provide accelerated fall-through to lowest power. At that point, you could probably merge the constraints. But the freezing part is also the hard part, isn't it? (I have no idea. Thomas seems to think about cgroups for that and doing smth about the timers.) 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 21:02:24 +1000 Neil Brown wrote: > > And this decision (to block suspend) really needs to be made in the driver, > not in userspace? Well, it fits. The requirement is a direct consequence of the intimate knowledge the driver has about the driven devices. Or if you get in an upper layer, the knowledge that the subsystem has about it's requirements to function properly. Why would you separate it out? If all your drivers specify their needed requirements, the pm-core (or idle) has the maximum flexibility to implement any strategy and is guaranteed a stable system as long as it honours the given requirements. (That's the theory, of course.) > > You could get those drivers to return EBUSY from PM_SUSPEND_PREPARE (which > would need to be a configurable option), but then I guess you have no way to > wait for the device to become non-busy. > > If user-space really cannot tell if the driver is busy or not, then I would > suggest that the driver is fairly poorly designed. In general, userspace has no business knowing if the driver is busy or not. It would need intimate knowledge about the driver to determine if it is busy or not. That is what the kernel is all about, to hide that knowledge from userspace and masking it with a one-fits-all-API. > > It would seem then that a user-space requested suspend is not sufficient for > your needs even if we remove the race window, as you have drivers that want > to avoid suspend indefinitely, and that "need to avoid suspend" status is not > visible from user-space. Well, but the kernel-solution and the userspace solution should be pretty independent. The tricky part here seems to be to have a kernel-userspace-boundary that doesn't require a specific kernel implementation and works. Could someone perhaps make a recap on what are the problems with the API? I have no clear eye (experience?) for that (or so it seems). > It is a pity that this extra requirement was not clear from your introduction > to the "Opportunistic suspend support" patch. I think that the main problem was that _all_ the requirements were not communicated well. That caused everybody to think that their solution would be a better fit. You are not alone. > If that be the case, I'll stop bothering you with suggestions that can never > work. > Thanks for your time, > NeilBrown Don't be frustrated. What should Arve be? :) 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, Jun 2, 2010 at 1:06 AM, Neil Brown wrote: > On Wed, 2 Jun 2010 00:05:14 -0700 > Arve Hjønnevåg wrote: >> > The user-space suspend daemon avoids losing wake-events by using >> > fcntl(F_OWNER) to ensure it gets a signal whenever any important wake-event >> > is ready to be read by user-space. This may involve: >> > - the one daemon processing all wake events >> >> Wake up events are not all processed by one daemon. > > Not with your current user-space code, no. Are you saying that you are not > open to any significant change in the Android user-space code? That would > make the situation a lot harder to resolve. There are many wakeup events possible in a typical system -- keypresses or other input events, network traffic, telephony events, media events (fill audio buffer, fill video decoder buffer, etc), and I think requiring that all wakeup event processing bottleneck through a single userspace process is non-optimal here. The current suspend-blocker proposal already involves userspace changes (it's different than our existing wakelock interface), and we're certainly not opposed to any/all userspace changes on principle, but on the other hand we're not interested in significant reworks of userspace unless they actually improve the situation somehow. I think bottlenecking events through a central daemon would represent a step backwards. 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] [PATCH 0/8] Suspend block api (version 8)
On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote: > 2010/6/1 James Bottomley : > > On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote: > >> On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley > >> wrote: > >> > On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote: > >> >> On Tuesday 01 June 2010, James Bottomley wrote: > >> >> > On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote: > >> >> > > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: > >> >> > > > >> >> > > > You're the one mentioning x86, not me. I already explained that > >> >> > > > some > >> >> > > > MSM hardware (the G1 for example) has lower power consumption in > >> >> > > > S3 > >> >> > > > (which I'm using as an ACPI shorthand for suspend to ram) than any > >> >> > > > suspend from idle C state. The fact that current x86 hardware > >> >> > > > has the > >> >> > > > same problem may be true, but it's not entirely relevant. > >> >> > > > >> >> > > As long as you can set a wakeup timer, an S state is just a C state > >> >> > > with > >> >> > > side effects. The significant one is that entering an S state stops > >> >> > > the > >> >> > > process scheduler and any in-kernel timers. I don't think Google > >> >> > > care at > >> >> > > all about whether suspend is entered through an explicit transition > >> >> > > or > >> >> > > something hooked into cpuidle - the relevant issue is that they > >> >> > > want to > >> >> > > be able to express a set of constraints that lets them control > >> >> > > whether > >> >> > > or not the scheduler keeps on scheduling, and which doesn't let them > >> >> > > lose wakeup events in the process. > >> >> > > >> >> > Exactly, so my understanding of where we currently are is: > >> >> > >> >> Thanks for the recap. > >> >> > >> >> > 1. pm_qos will be updated to be able to express the android > >> >> > suspend > >> >> > blockers as interactivity constraints (exact name TBD, but > >> >> > probably /dev/cpu_interactivity) > >> >> > >> >> I think that's not been decided yet precisely enough. I saw a few ideas > >> >> here and there in the thread, but which of them are we going to follow? > >> > > >> > Well, android only needs two states (block and don't block), so that > >> > gets translated as 2 s32 values (say 0 and INT_MAX). I've seen defines > >> > like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to > >> > describe these, but if all we're arguing over is the define name, that's > >> > progress. > >> > >> I think we need separate state constraints for suspend and idle low > >> power modes. On the msm platform only a subset of the interrupts can > >> wake up from the low power mode, so we block the use if the low power > >> mode from idle while other interrupts are enabled. We do not block > >> suspend however if those interrupts are not marked as wakeup > >> interrupts. Most constraints that prevent suspend are not hardware > >> specific and should not prevent entering low power modes from idle. In > >> other words we may need to prevent low power idle modes while allowing > >> suspend, and we may need to prevent suspend while allowing low power > >> idle modes. > > > > Well, as I said, pm_qos is s32 ... it's easy to make the constraint > > ternary instead of binary. > > No, they have to be two separate constraints, otherwise a constraint > to block suspend would override a constraint to block a low power idle > mode or the other way around. Depends. If you block the system from going into low power idle, does that mean you still want it to be fully suspended? If yes, then we do have independent constraints. If not, they have a hierarchy: * Fully Interactive (no low power idle or suspend) * Partially Interactive (may go into low power idle but not suspend) * None (may go into low power idle or suspend) Which is expressable as a ternary constraint. 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote: > 2010/6/2 Thomas Gleixner : > > On Wed, 2 Jun 2010, Arve Hjønnevåg wrote: > >> 2010/6/2 Neil Brown : > >> > There would still need to be some sort of communication between the the > >> > suspend daemon on any event daemon to ensure that the events had been > >> > processed. This could be very light weight interaction. The point > >> > though is > >> > that with this patch it becomes possible to avoid races. Possible is > >> > better > >> > than impossible. > >> > > >> > >> We already have a solution. I don't think rejecting our solution but > >> merging a worse solution should be the goal. > > > > That's not the goal at all. We want a solution which is acceptable for > > android and OTOH does not get into the way of other approaches. > > > > I don't actually think the suspend blocker patchset get in the way of > anything else. > > > The main problem I have is that suspend blockers are only addressing > > one particular problem space of power management. > > > > We have more requirements than that, e.g. an active device transfer > > requires to prevent the idle code to select a deep power state due to > > latency requirements. > > > > So we then have to implement two mechanisms in the relevant drivers: > > > > 1) telling the idle code to limit latency > > 2) telling the suspend code not to suspend > > And 3) telling the idle code to not enter low power modes that disrupt > active interrupts or clocks. > > Our wakelock code handles 2 and 3, but I removed support for 3 on > request since you can hack it by specifying a latency value that you > know the low power mode cannot support. You are mixing concepts. clock domains and power domains are a separate issue which are already handled by the run time power management code and the clock framework. The interrupt latency is a QoS requirement and has nothing to do with power domains and clock domains simply because I can go deeper w/o violating the clock and power domain constraints when the latency allows it. > > My main interest is to limit it to one mechanism, which is QoS based > > and let idle and suspend make the appropriate decisions based on that > > information. > > > > We can use one mechanism for this, but we still have to specify both. > To me this is just another naming argument and not a good reason to > not merge the suspend blocker code. You have to modify the same The main objection against suspend blocker is the user space interface / ABI issue, not the driver code which we can fix in no time. But we cannot fix it once it is glued into a user space interface. I don't care about adding two empty static inlines into a header file, which allows to merge the android drivers, but I care much about giving a guaranteed behaviour to user space. Thanks, tglx
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 02 Jun 2010 11:10:51 +0200 Peter Zijlstra wrote: > On Wed, 2010-06-02 at 10:29 +0200, Thomas Gleixner wrote: > > > > If I understood you correctly then you can shutdown the CPU in idle > > completelty already, but that's not enough due to: > > > > 1) crappy applications keeping the cpu away from idle > > 2) timers firing > > > > Would solving those two issues be sufficient for you or am I missing > > something ? > > Aren't the container snapshot/resume people fighting the same set of > problems here? And virtualisation - its a big one for virtualisation because if you've got 1000 misbehaving guests generating 100 wakeups a second you've got a problem 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 02:12:10 -0700 Arve Hjønnevåg wrote: > 2010/6/2 Neil Brown : > > On Wed, 2 Jun 2010 00:05:14 -0700 > > Arve Hjønnevåg wrote: > > > >> On Tue, Jun 1, 2010 at 10:32 PM, Neil Brown wrote: > >> > On Tue, 1 Jun 2010 12:50:01 +0200 (CEST) > >> > Thomas Gleixner wrote: > >> > > >> >> On Tue, 1 Jun 2010, Neil Brown wrote: > >> >> > > >> >> > I think you have acknowledged that there is a race with suspend - > >> >> > thanks. > >> >> > Next step was "can it be closed". > >> >> > You seem to suggest that it can, but you describe it as a "work > >> >> > around" > >> >> > rather than a "bug fix"... > >> >> > > >> >> > Do you agree that the race is a "bug", and therefore it is > >> >> > appropriate to > >> >> > "fix" it assuming an acceptable fix can be found (which I think it > >> >> > can)? > >> >> > >> >> If we can fix it, yes we definitely should do and not work around it. > >> >> > >> >> Thanks, > >> >> > >> >> tglx > >> > > >> > OK. > >> > Here is my suggestion. > >> > > >> > While I think this patch would actually work, and hope the ugly aspects > >> > are > >> > reasonably balanced by the simplicity, I present it primarily as a base > >> > for > >> > improvement. > >> > The important part is to present how drivers and user-space can > >> > co-operate > >> > to avoid losing wake-events. The details of what happens in the kernel > >> > are > >> > certainly up for discussion (as is everything else really of course). > >> > > >> > The user-space suspend daemon avoids losing wake-events by using > >> > fcntl(F_OWNER) to ensure it gets a signal whenever any important > >> > wake-event > >> > is ready to be read by user-space. This may involve: > >> > - the one daemon processing all wake events > >> > >> Wake up events are not all processed by one daemon. > > > > Not with your current user-space code, no. Are you saying that you are not > > open to any significant change in the Android user-space code? That would > > make the situation a lot harder to resolve. > > > > Some wakeup events like the an incoming phone may be handled by a > vendor supplied daemon that I do not have the source code for. And, no > I'm not open to a change that would require all wakeup events to go to > a single process. Ahh.. Well I have no answer for the "I must support a closed-source app" card that has not been heard 1000 times already. My proposal doesn't require all wakeup events to go through one single process - it was just one of (at least) 3 options. > > >> > >> > - Both the suspend daemon and the main event handling daemon opening any > >> > given device that delivers wake events (this should work with input > >> > events ... unless grabbing is needed) > >> > >> Not all wakeup events are broadcast like input events so they cannot > >> be read by both daemons. Not that this really matters, since reading > >> the event from the suspend daemon does not mean that it has been > >> delivered to and processed by the other daemon. > > > > There would still need to be some sort of communication between the the > > suspend daemon on any event daemon to ensure that the events had been > > processed. This could be very light weight interaction. The point though > > is > > that with this patch it becomes possible to avoid races. Possible is better > > than impossible. > > > > We already have a solution. I don't think rejecting our solution but > merging a worse solution should be the goal. > > >> > >> > - The event handling daemon giving the suspend-daemon's pid as F_OWNER, > >> > and > >> > using poll/select to get the events itself. > >> > >> I don't like the idea of using signals for this. Without the hack Alan > >> Stern suggested, you will temporarily block suspend if the wakeup > >> event happened before the suspend daemon thread made it to the kernel, > >> but abort suspend if it happened right after. > > > > I'm not sure why that difference matters. But I'm also not sure that it is > > true. > > When any wakeup event happen, a signal will be delivered to the suspend > > daemon. > > This will interrupt a pending suspend request, or a sleep, or whatever else > > the daemon is doing. > > It can then go back to waiting for a good time to suspend, and then try to > > suspend again. > > > > This is inferior to the solution that is in the android kernel and the > suspend blocker patchset. Both suspend as soon as possible and do not > require signal handlers that modify the argument to your kernel call. > The solution in the android kernel and the suspend blocker patchset both share one fairly fatal flaw - they are not being accepted upstream. I am trying to find a minimal suitable solution that does not share that flaw. I do not know yet if it does or not, but as it is fixing a real (design) bug, I feel it has some chance. Of course if it doesn't meet your need, then that becomes irrelevant And there is no requirement to modify any arguments in any signal handlers. >
Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 10:50:39 +0200 Florian Mickler wrote: > On Wed, 2 Jun 2010 18:06:14 +1000 > Neil Brown wrote: > > > I cannot imagine why it would take multiple seconds to scan a keypad. > > Can you explain that? > > > > Do you mean while keys are held pressed? Maybe you don't get a wake-up > > event > > on key-release? In that case your user-space daemon could block suspend > > while there are any pressed keys confused. > > IIRC, the device sends interrupts only for first key-down and > last key-up. > To detect simultaneous key-presses you must actively scan it after the > first key-down. That makes sense - thanks. Presumably the first key-press gets to user-space promptly, so the user-space suspend daemon can be told not to suspend until the last key-up. Thanks, NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-06-02 at 03:00 -0700, Arve Hjønnevåg wrote: > 2010/6/2 Peter Zijlstra : > > On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote: > >> No I want you to stop confusing low power idle modes with suspend. > > > > I think it is you who is confused. For power management purposes suspend > > is nothing more but a deep idle state. > > No, idle is transparent, suspend is not. Which is where the problem is, it should be. > Why would I add suspend blockers to the code I want to prevent running? Because what you want might not be what others want. Suppose you're fine with your torrent client/irc client/etc.. to loose their network connection when you're not behind your desktop so you don't add suspend blockers there. Me, I'd be ready to administer physical violence if either of those lost their connections when I wasn't around to keep the screen-saver from kicking in. This leads to having to sprinkle magic dust (and lots of config options) all over userspace. Something that gets esp interesting with only a boolean interface. In the example above, having an active net connection would prevent my desktop from suspending, but what if another platform can maintain net connections while suspended? Do we then end up with arch specific code in the net-stack? I'm sure DaveM would love that. -- 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] [PATCH 0/8] Suspend block api (version 8)
2010/6/2 Peter Zijlstra : > On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote: >> No I want you to stop confusing low power idle modes with suspend. > > I think it is you who is confused. For power management purposes suspend > is nothing more but a deep idle state. No, idle is transparent, suspend is not. > > (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're > fixing it, get over it already). > I don't think it is realistic to drop support for all existing hardware. >> Unrelated to >> Android, I also want to use opportunistic suspend on my desktop. > > So you're going to sprinkle this suspend blocker shite all over regular > userspace? I have said several times, that regular user-space will not need to be modified to maintain their current behavior. > Why not instead work on getting apps to behave properly and > idle when there's nothing to do? > > After all, if you have the code to add suspend blockers into, you also > have the means to fix it being stupid in the first place. > Why would I add suspend blockers to the code I want to prevent running? -- 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/2 Thomas Gleixner : > On Wed, 2 Jun 2010, Arve Hjønnevåg wrote: >> 2010/6/2 Neil Brown : >> > There would still need to be some sort of communication between the the >> > suspend daemon on any event daemon to ensure that the events had been >> > processed. This could be very light weight interaction. The point though >> > is >> > that with this patch it becomes possible to avoid races. Possible is >> > better >> > than impossible. >> > >> >> We already have a solution. I don't think rejecting our solution but >> merging a worse solution should be the goal. > > That's not the goal at all. We want a solution which is acceptable for > android and OTOH does not get into the way of other approaches. > I don't actually think the suspend blocker patchset get in the way of anything else. > The main problem I have is that suspend blockers are only addressing > one particular problem space of power management. > > We have more requirements than that, e.g. an active device transfer > requires to prevent the idle code to select a deep power state due to > latency requirements. > > So we then have to implement two mechanisms in the relevant drivers: > > 1) telling the idle code to limit latency > 2) telling the suspend code not to suspend And 3) telling the idle code to not enter low power modes that disrupt active interrupts or clocks. Our wakelock code handles 2 and 3, but I removed support for 3 on request since you can hack it by specifying a latency value that you know the low power mode cannot support. > > My main interest is to limit it to one mechanism, which is QoS based > and let idle and suspend make the appropriate decisions based on that > information. > We can use one mechanism for this, but we still have to specify both. To me this is just another naming argument and not a good reason to not merge the suspend blocker code. You have to modify the same drivers if you call suspend_block() as if you call pm_qos_update_requirement(don't suspend). We have to specify when it is not safe to suspend independent of when it is not safe to enter low power idle modes so unless you want to have a bitmap of constraints you don't save any calls. And, if we later get a constraint framework that supports everything, we can switch to it then and we will then already have some drivers annotated. -- 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] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote: > No I want you to stop confusing low power idle modes with suspend. I think it is you who is confused. For power management purposes suspend is nothing more but a deep idle state. (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're fixing it, get over it already). > Unrelated to > Android, I also want to use opportunistic suspend on my desktop. So you're going to sprinkle this suspend blocker shite all over regular userspace? Why not instead work on getting apps to behave properly and idle when there's nothing to do? After all, if you have the code to add suspend blockers into, you also have the means to fix it being stupid in the first place. -- 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote: > 2010/6/2 Neil Brown : > > There would still need to be some sort of communication between the the > > suspend daemon on any event daemon to ensure that the events had been > > processed. This could be very light weight interaction. The point though > > is > > that with this patch it becomes possible to avoid races. Possible is better > > than impossible. > > > > We already have a solution. I don't think rejecting our solution but > merging a worse solution should be the goal. That's not the goal at all. We want a solution which is acceptable for android and OTOH does not get into the way of other approaches. The main problem I have is that suspend blockers are only addressing one particular problem space of power management. We have more requirements than that, e.g. an active device transfer requires to prevent the idle code to select a deep power state due to latency requirements. So we then have to implement two mechanisms in the relevant drivers: 1) telling the idle code to limit latency 2) telling the suspend code not to suspend My main interest is to limit it to one mechanism, which is QoS based and let idle and suspend make the appropriate decisions based on that information. Thanks, tglx
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/2 Thomas Gleixner : > On Wed, 2 Jun 2010, Arve Hjønnevåg wrote: >> 2010/6/2 Thomas Gleixner : >> > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: >> >> >> >> Because suspend itself causes you to not be idle you cannot abort >> >> suspend just because you are not idle anymore. >> > >> > You still are addicted to the current suspend mechanism. :) >> > >> >> No I want you to stop confusing low power idle modes with suspend. I >> know how to enter low power modes from idle if that low power mode is >> not too disruptive. > > What prevents us from going into a disruptive mode from idle ? I don't > see a reason - except crappy ACPI stuff, which I'm happy to ignore. > What do you consider disruptive? Disabling active interrupts? Stopping the monotonic clock? >> > If I understood you correctly then you can shutdown the CPU in idle >> > completelty already, but that's not enough due to: >> > >> > 1) crappy applications keeping the cpu away from idle >> > 2) timers firing >> > >> > Would solving those two issues be sufficient for you or am I missing >> > something ? >> >> Solving those two is enough for current android phones, but it may not >> be enough for other android devices. > > In which way ? May not be enough is a pretty vague statement. They may not be based on hardware that can get to the same power mode from idle as suspend. This could be acpi based hardware, it could be like the hardware we started with that did not have regular timers that could run in the low power mode, or devices could loose their state in the lowest power mode. > >> 1 is not solvable (meaning we cannot fix all apps), > > We can mitigate it with cgroups and confine crap there, i.e. force > idle them. > I think using suspend is much simpler. It avoids having to worry about dependencies between processes. >> and 2 is difficult to fix since the periodic >> work is useful while the device is actually in use. One possible way >> to solve 2 is to allow timers on a not-idle clock. > > That's what I had in mind. > >> Unrelated to Android, I also want to use opportunistic suspend on my >> desktop. > > I expect that intel/amd fixing their stuff is going to happen way > before we sprinkled suspend blockers over a full featured desktop > distro. > You do not need to sprinkle suspend blocker all over the distro for it to be useful. You can convert the existing auto-suspend code to use opportunistic suspend and all apps that don't use suspend blocker will behave as they do today while allowing apps to use suspend blockers to keep the system running after the auto-suspend timeout expired. -- 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/2 Neil Brown : > On Wed, 2 Jun 2010 00:05:14 -0700 > Arve Hjønnevåg wrote: > >> On Tue, Jun 1, 2010 at 10:32 PM, Neil Brown wrote: >> > On Tue, 1 Jun 2010 12:50:01 +0200 (CEST) >> > Thomas Gleixner wrote: >> > >> >> On Tue, 1 Jun 2010, Neil Brown wrote: >> >> > >> >> > I think you have acknowledged that there is a race with suspend - >> >> > thanks. >> >> > Next step was "can it be closed". >> >> > You seem to suggest that it can, but you describe it as a "work around" >> >> > rather than a "bug fix"... >> >> > >> >> > Do you agree that the race is a "bug", and therefore it is appropriate >> >> > to >> >> > "fix" it assuming an acceptable fix can be found (which I think it can)? >> >> >> >> If we can fix it, yes we definitely should do and not work around it. >> >> >> >> Thanks, >> >> >> >> tglx >> > >> > OK. >> > Here is my suggestion. >> > >> > While I think this patch would actually work, and hope the ugly aspects are >> > reasonably balanced by the simplicity, I present it primarily as a base for >> > improvement. >> > The important part is to present how drivers and user-space can co-operate >> > to avoid losing wake-events. The details of what happens in the kernel are >> > certainly up for discussion (as is everything else really of course). >> > >> > The user-space suspend daemon avoids losing wake-events by using >> > fcntl(F_OWNER) to ensure it gets a signal whenever any important wake-event >> > is ready to be read by user-space. This may involve: >> > - the one daemon processing all wake events >> >> Wake up events are not all processed by one daemon. > > Not with your current user-space code, no. Are you saying that you are not > open to any significant change in the Android user-space code? That would > make the situation a lot harder to resolve. > Some wakeup events like the an incoming phone may be handled by a vendor supplied daemon that I do not have the source code for. And, no I'm not open to a change that would require all wakeup events to go to a single process. >> >> > - Both the suspend daemon and the main event handling daemon opening any >> > given device that delivers wake events (this should work with input >> > events ... unless grabbing is needed) >> >> Not all wakeup events are broadcast like input events so they cannot >> be read by both daemons. Not that this really matters, since reading >> the event from the suspend daemon does not mean that it has been >> delivered to and processed by the other daemon. > > There would still need to be some sort of communication between the the > suspend daemon on any event daemon to ensure that the events had been > processed. This could be very light weight interaction. The point though is > that with this patch it becomes possible to avoid races. Possible is better > than impossible. > We already have a solution. I don't think rejecting our solution but merging a worse solution should be the goal. >> >> > - The event handling daemon giving the suspend-daemon's pid as F_OWNER, >> > and >> > using poll/select to get the events itself. >> >> I don't like the idea of using signals for this. Without the hack Alan >> Stern suggested, you will temporarily block suspend if the wakeup >> event happened before the suspend daemon thread made it to the kernel, >> but abort suspend if it happened right after. > > I'm not sure why that difference matters. But I'm also not sure that it is > true. > When any wakeup event happen, a signal will be delivered to the suspend > daemon. > This will interrupt a pending suspend request, or a sleep, or whatever else > the daemon is doing. > It can then go back to waiting for a good time to suspend, and then try to > suspend again. > This is inferior to the solution that is in the android kernel and the suspend blocker patchset. Both suspend as soon as possible and do not require signal handlers that modify the argument to your kernel call. > >> >> > >> > When 'mem' is written to /sys/power/state, suspend_prepare waits in an >> > interruptible wait until any wake-event that might have been initiated >> > before >> > the suspend was request, has had a chance to be queued for user-space and >> > trigger kill_fasync. >> >> And what happens if you are not waiting when this happens? > > I'm not sure I understand the question. Could you explain it please? > If the thread is not already in the kernel how does your signal handler abort suspend. > Either the initial event happens late enough to abort/resume the suspend, or > the signal happens early enough to abort the suspend, or alert the daemon not > to do a suspend. Either way we don't get stuck in suspend. > > >> >> > Currently this wait is a configurable time after the last wake-event was >> > initiated. This is hackish, but simple and probably adequate. >> >> Waiting after a wake event is the same as suspend_block_timeout. This >> is useful when passing events through layers of code that does no >> block suspend,
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2010-06-02 at 10:29 +0200, Thomas Gleixner wrote: > If I understood you correctly then you can shutdown the CPU in idle > completelty already, but that's not enough due to: > > 1) crappy applications keeping the cpu away from idle > 2) timers firing > > Would solving those two issues be sufficient for you or am I missing > something ? Aren't the container snapshot/resume people fighting the same set of problems 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] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote: > 2010/6/2 Thomas Gleixner : > > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: > >> > >> Because suspend itself causes you to not be idle you cannot abort > >> suspend just because you are not idle anymore. > > > > You still are addicted to the current suspend mechanism. :) > > > > No I want you to stop confusing low power idle modes with suspend. I > know how to enter low power modes from idle if that low power mode is > not too disruptive. What prevents us from going into a disruptive mode from idle ? I don't see a reason - except crappy ACPI stuff, which I'm happy to ignore. > > If I understood you correctly then you can shutdown the CPU in idle > > completelty already, but that's not enough due to: > > > > 1) crappy applications keeping the cpu away from idle > > 2) timers firing > > > > Would solving those two issues be sufficient for you or am I missing > > something ? > > Solving those two is enough for current android phones, but it may not > be enough for other android devices. In which way ? May not be enough is a pretty vague statement. > 1 is not solvable (meaning we cannot fix all apps), We can mitigate it with cgroups and confine crap there, i.e. force idle them. > and 2 is difficult to fix since the periodic > work is useful while the device is actually in use. One possible way > to solve 2 is to allow timers on a not-idle clock. That's what I had in mind. > Unrelated to Android, I also want to use opportunistic suspend on my > desktop. I expect that intel/amd fixing their stuff is going to happen way before we sprinkled suspend blockers over a full featured desktop distro. Thanks, tglx
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/2 Thomas Gleixner : > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: >> 2010/6/1 Thomas Gleixner : >> > On Mon, 31 May 2010, Arve Hjønnevåg wrote: >> > >> >> 2010/5/31 Rafael J. Wysocki : >> >> > On Monday 31 May 2010, Arve Hjønnevåg wrote: >> >> >> 2010/5/30 Rafael J. Wysocki : >> >> > ... >> >> >> >> >> >> I think it makes more sense to block suspend while wakeup events are >> >> >> pending than blocking it everywhere timers are used by code that could >> >> >> be called while handling wakeup events or other critical work. Also, >> >> >> even if you did block suspend everywhere timers where used you still >> >> >> have the race where a wakeup interrupt happens right after you decided >> >> >> to suspend. In other words, you still need to block suspend in all the >> >> >> same places as with the current opportunistic suspend code, so what is >> >> >> the benefit of delaying suspend until idle? >> >> > >> >> > Assume for a while that you don't use suspend blockers, OK? I realize >> >> > you >> >> > think that anything else doesn't make sense, but evidently some other >> >> > people >> >> > have that opinion about suspend blockers. >> >> > >> >> >> >> It sounded like you were suggesting that initiating suspend from idle >> >> would somehow avoid the race condition with wakeup events. All I'm >> >> saying is that you would need to block suspend in all the same places. >> >> If you don't care about ignoring wakeup events, then sure you can >> >> initiate suspend from idle. >> > >> > And why should you miss a wakeup there ? If you get an interrupt in >> > the transition, then you are not longer idle. >> > >> >> Because suspend itself causes you to not be idle you cannot abort >> suspend just because you are not idle anymore. > > You still are addicted to the current suspend mechanism. :) > No I want you to stop confusing low power idle modes with suspend. I know how to enter low power modes from idle if that low power mode is not too disruptive. > The whole point of doing it from idle in the form of a deep power > state is to avoid the massive sh*tload of work which is neccesary to > run the existing suspend code. But that needs runtime power management > and tweaks to avoid your timers waking you, etc. > > The mechanism you want to use is: suspend no matter what, like closing > the lid of the laptop, but with a few tweaks around it: > > 1) An interrupt on a wakeup source which comes in while the suspend > code runs, i.e before you transitioned into wakeup mode, must > abort / prevent suspend. > > 2) Prevent another attempt to suspend before the event has been > delivered and the apps have signaled that they have not longer > any work to do. > > As a side effect you confine crappy apps with that mechanism in > some way. > > In the laptop case we do not want the tweaks as not going into suspend > might set your backpack on fire. If that is the case you should also disable the wakeup events. > > If I understood you correctly then you can shutdown the CPU in idle > completelty already, but that's not enough due to: > > 1) crappy applications keeping the cpu away from idle > 2) timers firing > > Would solving those two issues be sufficient for you or am I missing > something ? Solving those two is enough for current android phones, but it may not be enough for other android devices. 1 is not solvable (meaning we cannot fix all apps), and 2 is difficult to fix since the periodic work is useful while the device is actually in use. One possible way to solve 2 is to allow timers on a not-idle clock. Unrelated to Android, I also want to use opportunistic suspend on my desktop. -- 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 18:06:14 +1000 Neil Brown wrote: > I cannot imagine why it would take multiple seconds to scan a keypad. > Can you explain that? > > Do you mean while keys are held pressed? Maybe you don't get a wake-up event > on key-release? In that case your user-space daemon could block suspend > while there are any pressed keys confused. IIRC, the device sends interrupts only for first key-down and last key-up. To detect simultaneous key-presses you must actively scan it after the first key-down. > > -- > 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 > -- 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] [PATCH 0/8] Suspend block api (version 8)
On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: > 2010/6/1 Thomas Gleixner : > > On Mon, 31 May 2010, Arve Hjønnevåg wrote: > > > >> 2010/5/31 Rafael J. Wysocki : > >> > On Monday 31 May 2010, Arve Hjønnevåg wrote: > >> >> 2010/5/30 Rafael J. Wysocki : > >> > ... > >> >> > >> >> I think it makes more sense to block suspend while wakeup events are > >> >> pending than blocking it everywhere timers are used by code that could > >> >> be called while handling wakeup events or other critical work. Also, > >> >> even if you did block suspend everywhere timers where used you still > >> >> have the race where a wakeup interrupt happens right after you decided > >> >> to suspend. In other words, you still need to block suspend in all the > >> >> same places as with the current opportunistic suspend code, so what is > >> >> the benefit of delaying suspend until idle? > >> > > >> > Assume for a while that you don't use suspend blockers, OK? I realize > >> > you > >> > think that anything else doesn't make sense, but evidently some other > >> > people > >> > have that opinion about suspend blockers. > >> > > >> > >> It sounded like you were suggesting that initiating suspend from idle > >> would somehow avoid the race condition with wakeup events. All I'm > >> saying is that you would need to block suspend in all the same places. > >> If you don't care about ignoring wakeup events, then sure you can > >> initiate suspend from idle. > > > > And why should you miss a wakeup there ? If you get an interrupt in > > the transition, then you are not longer idle. > > > > Because suspend itself causes you to not be idle you cannot abort > suspend just because you are not idle anymore. You still are addicted to the current suspend mechanism. :) The whole point of doing it from idle in the form of a deep power state is to avoid the massive sh*tload of work which is neccesary to run the existing suspend code. But that needs runtime power management and tweaks to avoid your timers waking you, etc. The mechanism you want to use is: suspend no matter what, like closing the lid of the laptop, but with a few tweaks around it: 1) An interrupt on a wakeup source which comes in while the suspend code runs, i.e before you transitioned into wakeup mode, must abort / prevent suspend. 2) Prevent another attempt to suspend before the event has been delivered and the apps have signaled that they have not longer any work to do. As a side effect you confine crappy apps with that mechanism in some way. In the laptop case we do not want the tweaks as not going into suspend might set your backpack on fire. If I understood you correctly then you can shutdown the CPU in idle completelty already, but that's not enough due to: 1) crappy applications keeping the cpu away from idle 2) timers firing Would solving those two issues be sufficient for you or am I missing something ? Thanks, tglx
Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010 00:05:14 -0700 Arve Hjønnevåg wrote: > On Tue, Jun 1, 2010 at 10:32 PM, Neil Brown wrote: > > On Tue, 1 Jun 2010 12:50:01 +0200 (CEST) > > Thomas Gleixner wrote: > > > >> On Tue, 1 Jun 2010, Neil Brown wrote: > >> > > >> > I think you have acknowledged that there is a race with suspend - thanks. > >> > Next step was "can it be closed". > >> > You seem to suggest that it can, but you describe it as a "work around" > >> > rather than a "bug fix"... > >> > > >> > Do you agree that the race is a "bug", and therefore it is appropriate to > >> > "fix" it assuming an acceptable fix can be found (which I think it can)? > >> > >> If we can fix it, yes we definitely should do and not work around it. > >> > >> Thanks, > >> > >> tglx > > > > OK. > > Here is my suggestion. > > > > While I think this patch would actually work, and hope the ugly aspects are > > reasonably balanced by the simplicity, I present it primarily as a base for > > improvement. > > The important part is to present how drivers and user-space can co-operate > > to avoid losing wake-events. The details of what happens in the kernel are > > certainly up for discussion (as is everything else really of course). > > > > The user-space suspend daemon avoids losing wake-events by using > > fcntl(F_OWNER) to ensure it gets a signal whenever any important wake-event > > is ready to be read by user-space. This may involve: > > - the one daemon processing all wake events > > Wake up events are not all processed by one daemon. Not with your current user-space code, no. Are you saying that you are not open to any significant change in the Android user-space code? That would make the situation a lot harder to resolve. > > > - Both the suspend daemon and the main event handling daemon opening any > > given device that delivers wake events (this should work with input > > events ... unless grabbing is needed) > > Not all wakeup events are broadcast like input events so they cannot > be read by both daemons. Not that this really matters, since reading > the event from the suspend daemon does not mean that it has been > delivered to and processed by the other daemon. There would still need to be some sort of communication between the the suspend daemon on any event daemon to ensure that the events had been processed. This could be very light weight interaction. The point though is that with this patch it becomes possible to avoid races. Possible is better than impossible. > > > - The event handling daemon giving the suspend-daemon's pid as F_OWNER, and > > using poll/select to get the events itself. > > I don't like the idea of using signals for this. Without the hack Alan > Stern suggested, you will temporarily block suspend if the wakeup > event happened before the suspend daemon thread made it to the kernel, > but abort suspend if it happened right after. I'm not sure why that difference matters. But I'm also not sure that it is true. When any wakeup event happen, a signal will be delivered to the suspend daemon. This will interrupt a pending suspend request, or a sleep, or whatever else the daemon is doing. It can then go back to waiting for a good time to suspend, and then try to suspend again. > > > > > When 'mem' is written to /sys/power/state, suspend_prepare waits in an > > interruptible wait until any wake-event that might have been initiated > > before > > the suspend was request, has had a chance to be queued for user-space and > > trigger kill_fasync. > > And what happens if you are not waiting when this happens? I'm not sure I understand the question. Could you explain it please? Either the initial event happens late enough to abort/resume the suspend, or the signal happens early enough to abort the suspend, or alert the daemon not to do a suspend. Either way we don't get stuck in suspend. > > > Currently this wait is a configurable time after the last wake-event was > > initiated. This is hackish, but simple and probably adequate. > > Waiting after a wake event is the same as suspend_block_timeout. This > is useful when passing events through layers of code that does no > block suspend, but we should strive to avoid it. Other people had much > stronger objections to this, which is why it is not included in the > last suspend blocker patchset. Absolutely agree. The idea of of waiting was just a simple way to present code that actually could work. There are doubtlessly better ways and I assume they have been implemented in the suspend-blocker code. We just need some way to wait for the suspend-block count to reach zero, with some confidence that this amount of time is limited. (though to be honest ... the incredible simplicity of waiting a little while is very compelling :-)) > > It also does not work for drivers that need to block suspend for more > than a few seconds. For instance the gpio keypad matrix driver needs > to block suspend while keys are pressed so it can sc
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote: > 2010/6/2 Thomas Gleixner : > > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: > >> Deferring the the timers forever without stopping the clock can cause > >> problems. Our user space code has a lot of timeouts that will trigger > >> an error if an app does not respond in time. Freezing everything and > >> stopping the clock while suspended is a lot simpler than trying to > >> stop individual timers and processes from running. > > > > And resume updates timekeeping to account for the slept time. So the > > No, for the monotonic clock it does the opposite. The hardware clock > is read on resume and the offset is set so the monotonic clock gets > the same value as it had when suspend was called. Grr, yes. Misread the code. -ENOTENOUGHCOFFEE Thanks, tglx
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/2 Thomas Gleixner : > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: >> 2010/6/1 Thomas Gleixner : >> > >> > On Mon, 31 May 2010, Arve Hjønnevåg wrote: >> > >> >> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner >> >> wrote: >> >> > On Mon, 31 May 2010, James Bottomley wrote: >> >> >> >> >> >> For MSM hardware, it looks possible to unify the S and C states by >> >> >> doing >> >> >> suspend to ram from idle but I'm not sure how much work that is. >> >> > >> >> > On ARM, it's not rocket science and we have in tree support for this >> >> > already (OMAP). I have done the same thing on a Samsung part as a >> >> > prove of concept two years ago and it's really easy as the hardware is >> >> > sane. Hint: It's designed for mobile devices :) >> >> > >> >> >> >> We already enter the same power state from idle and suspend on msm. In >> >> the absence of misbehaving apps, the difference in power consumption >> >> is entirely caused by periodic timers in the user-space framework >> >> _and_ kernel. It only takes a few timers triggering per second (I >> >> think 3 if they do no work) to double the average power consumption on >> >> the G1 if the radio is off. We originally added wakelocks because the >> >> hardware we had at the time had much lower power consumption in >> >> suspend then idle, but we still use suspend because it saves power. >> > >> > So how do you differentiate between timers which _should_ fire and >> > those you do not care about ? >> > >> >> Only alarms are allowed to fire while suspended. >> >> > We have mechanisms in place to defer timers so the wakeups are >> > minimized. If that's not enough we need to revisit. >> > >> >> Deferring the the timers forever without stopping the clock can cause >> problems. Our user space code has a lot of timeouts that will trigger >> an error if an app does not respond in time. Freezing everything and >> stopping the clock while suspended is a lot simpler than trying to >> stop individual timers and processes from running. > > And resume updates timekeeping to account for the slept time. So the No, for the monotonic clock it does the opposite. The hardware clock is read on resume and the offset is set so the monotonic clock gets the same value as it had when suspend was called. > only way to get away with that is to sleep under a second or just > ignoring the update by avoiding the access to rtc. > > So how do you keep timekeeping happy ? > -- 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: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, Jun 1, 2010 at 10:32 PM, Neil Brown wrote:
> On Tue, 1 Jun 2010 12:50:01 +0200 (CEST)
> Thomas Gleixner wrote:
>
>> On Tue, 1 Jun 2010, Neil Brown wrote:
>> >
>> > I think you have acknowledged that there is a race with suspend - thanks.
>> > Next step was "can it be closed".
>> > You seem to suggest that it can, but you describe it as a "work around"
>> > rather than a "bug fix"...
>> >
>> > Do you agree that the race is a "bug", and therefore it is appropriate to
>> > "fix" it assuming an acceptable fix can be found (which I think it can)?
>>
>> If we can fix it, yes we definitely should do and not work around it.
>>
>> Thanks,
>>
>> tglx
>
> OK.
> Here is my suggestion.
>
> While I think this patch would actually work, and hope the ugly aspects are
> reasonably balanced by the simplicity, I present it primarily as a base for
> improvement.
> The important part is to present how drivers and user-space can co-operate
> to avoid losing wake-events. The details of what happens in the kernel are
> certainly up for discussion (as is everything else really of course).
>
> The user-space suspend daemon avoids losing wake-events by using
> fcntl(F_OWNER) to ensure it gets a signal whenever any important wake-event
> is ready to be read by user-space. This may involve:
> - the one daemon processing all wake events
Wake up events are not all processed by one daemon.
> - Both the suspend daemon and the main event handling daemon opening any
> given device that delivers wake events (this should work with input
> events ... unless grabbing is needed)
Not all wakeup events are broadcast like input events so they cannot
be read by both daemons. Not that this really matters, since reading
the event from the suspend daemon does not mean that it has been
delivered to and processed by the other daemon.
> - The event handling daemon giving the suspend-daemon's pid as F_OWNER, and
> using poll/select to get the events itself.
I don't like the idea of using signals for this. Without the hack Alan
Stern suggested, you will temporarily block suspend if the wakeup
event happened before the suspend daemon thread made it to the kernel,
but abort suspend if it happened right after.
>
> When 'mem' is written to /sys/power/state, suspend_prepare waits in an
> interruptible wait until any wake-event that might have been initiated before
> the suspend was request, has had a chance to be queued for user-space and
> trigger kill_fasync.
And what happens if you are not waiting when this happens?
> Currently this wait is a configurable time after the last wake-event was
> initiated. This is hackish, but simple and probably adequate.
Waiting after a wake event is the same as suspend_block_timeout. This
is useful when passing events through layers of code that does no
block suspend, but we should strive to avoid it. Other people had much
stronger objections to this, which is why it is not included in the
last suspend blocker patchset.
It also does not work for drivers that need to block suspend for more
than a few seconds. For instance the gpio keypad matrix driver needs
to block suspend while keys are pressed so it can scan the keypad.
> If more precise timing is needed and achievable, that can be added later. It
> would be an entirely internal change and would not affect the API further.
> Some of the code developed for suspend-blockers might be a starting point for
> this.
>
> Drivers should call pm_suspend_delay() whenever a wake-event occurs. This
> simply records the time so that the suspend process knows if there is in fact
> any need to wait at all.
>
> The delay to wait after the last pm_suspend_delay() is limited to 10 seconds
> and can be set by kernel parameter suspend_block_delay=number-of-milliseconds
> It defaults to 2 jiffies (which is possibly too short).
>
> - Would this fix the "bug"??
> - and address the issues that suspend-blockers was created to address?
> - or are the requirements on user-space too onerous?
>
>
> Thanks,
> NeilBrown
>
> Signed-off-by: NeilBrown
>
> diff --git a/include/linux/suspend.h b/include/linux/suspend.h
> index 5e781d8..ccbadd0 100644
> --- a/include/linux/suspend.h
> +++ b/include/linux/suspend.h
> @@ -142,11 +142,13 @@ extern void arch_suspend_disable_irqs(void);
> extern void arch_suspend_enable_irqs(void);
>
> extern int pm_suspend(suspend_state_t state);
> +extern void pm_suspend_delay(void);
> #else /* !CONFIG_SUSPEND */
> #define suspend_valid_only_mem NULL
>
> static inline void suspend_set_ops(struct platform_suspend_ops *ops) {}
> static inline int pm_suspend(suspend_state_t state) { return -ENOSYS; }
> +static inlint void pm_suspend_delay(void) {}
> #endif /* !CONFIG_SUSPEND */
>
> /* struct pbe is used for creating lists of pages that should be restored
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index 56e7dbb..07897b9 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -46,6 +46,69 @@ boo
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: > 2010/6/1 Thomas Gleixner : > > > > On Mon, 31 May 2010, Arve Hjønnevåg wrote: > > > >> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner > >> wrote: > >> > On Mon, 31 May 2010, James Bottomley wrote: > >> >> > >> >> For MSM hardware, it looks possible to unify the S and C states by doing > >> >> suspend to ram from idle but I'm not sure how much work that is. > >> > > >> > On ARM, it's not rocket science and we have in tree support for this > >> > already (OMAP). I have done the same thing on a Samsung part as a > >> > prove of concept two years ago and it's really easy as the hardware is > >> > sane. Hint: It's designed for mobile devices :) > >> > > >> > >> We already enter the same power state from idle and suspend on msm. In > >> the absence of misbehaving apps, the difference in power consumption > >> is entirely caused by periodic timers in the user-space framework > >> _and_ kernel. It only takes a few timers triggering per second (I > >> think 3 if they do no work) to double the average power consumption on > >> the G1 if the radio is off. We originally added wakelocks because the > >> hardware we had at the time had much lower power consumption in > >> suspend then idle, but we still use suspend because it saves power. > > > > So how do you differentiate between timers which _should_ fire and > > those you do not care about ? > > > > Only alarms are allowed to fire while suspended. > > > We have mechanisms in place to defer timers so the wakeups are > > minimized. If that's not enough we need to revisit. > > > > Deferring the the timers forever without stopping the clock can cause > problems. Our user space code has a lot of timeouts that will trigger > an error if an app does not respond in time. Freezing everything and > stopping the clock while suspended is a lot simpler than trying to > stop individual timers and processes from running. And resume updates timekeeping to account for the slept time. So the only way to get away with that is to sleep under a second or just ignoring the update by avoiding the access to rtc. So how do you keep timekeeping happy ? Thanks, tglx
[PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 1 Jun 2010 12:50:01 +0200 (CEST)
Thomas Gleixner wrote:
> On Tue, 1 Jun 2010, Neil Brown wrote:
> >
> > I think you have acknowledged that there is a race with suspend - thanks.
> > Next step was "can it be closed".
> > You seem to suggest that it can, but you describe it as a "work around"
> > rather than a "bug fix"...
> >
> > Do you agree that the race is a "bug", and therefore it is appropriate to
> > "fix" it assuming an acceptable fix can be found (which I think it can)?
>
> If we can fix it, yes we definitely should do and not work around it.
>
> Thanks,
>
> tglx
OK.
Here is my suggestion.
While I think this patch would actually work, and hope the ugly aspects are
reasonably balanced by the simplicity, I present it primarily as a base for
improvement.
The important part is to present how drivers and user-space can co-operate
to avoid losing wake-events. The details of what happens in the kernel are
certainly up for discussion (as is everything else really of course).
The user-space suspend daemon avoids losing wake-events by using
fcntl(F_OWNER) to ensure it gets a signal whenever any important wake-event
is ready to be read by user-space. This may involve:
- the one daemon processing all wake events
- Both the suspend daemon and the main event handling daemon opening any
given device that delivers wake events (this should work with input
events ... unless grabbing is needed)
- The event handling daemon giving the suspend-daemon's pid as F_OWNER, and
using poll/select to get the events itself.
When 'mem' is written to /sys/power/state, suspend_prepare waits in an
interruptible wait until any wake-event that might have been initiated before
the suspend was request, has had a chance to be queued for user-space and
trigger kill_fasync.
Currently this wait is a configurable time after the last wake-event was
initiated. This is hackish, but simple and probably adequate.
If more precise timing is needed and achievable, that can be added later. It
would be an entirely internal change and would not affect the API further.
Some of the code developed for suspend-blockers might be a starting point for
this.
Drivers should call pm_suspend_delay() whenever a wake-event occurs. This
simply records the time so that the suspend process knows if there is in fact
any need to wait at all.
The delay to wait after the last pm_suspend_delay() is limited to 10 seconds
and can be set by kernel parameter suspend_block_delay=number-of-milliseconds
It defaults to 2 jiffies (which is possibly too short).
- Would this fix the "bug"??
- and address the issues that suspend-blockers was created to address?
- or are the requirements on user-space too onerous?
Thanks,
NeilBrown
Signed-off-by: NeilBrown
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 5e781d8..ccbadd0 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -142,11 +142,13 @@ extern void arch_suspend_disable_irqs(void);
extern void arch_suspend_enable_irqs(void);
extern int pm_suspend(suspend_state_t state);
+extern void pm_suspend_delay(void);
#else /* !CONFIG_SUSPEND */
#define suspend_valid_only_mem NULL
static inline void suspend_set_ops(struct platform_suspend_ops *ops) {}
static inline int pm_suspend(suspend_state_t state) { return -ENOSYS; }
+static inlint void pm_suspend_delay(void) {}
#endif /* !CONFIG_SUSPEND */
/* struct pbe is used for creating lists of pages that should be restored
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 56e7dbb..07897b9 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -46,6 +46,69 @@ bool valid_state(suspend_state_t state)
return suspend_ops && suspend_ops->valid && suspend_ops->valid(state);
}
+/*
+ * Devices that process potential wake-up events report each
+ * wake-up events by pm_suspend_delay();
+ * This ensures that suspend won't happen for a "little while"
+ * so the event has a chance to get to user-space.
+ * pm_suspend calls wait_for_blockers to wait the required
+ * "little while" and to check for signals.
+ * A process that requests a suspend should arrange (via
+ * fcntl(F_GETOWN)) to get signalled whenever a wake-up event
+ * is queued for user-space. This will ensure that if a suspend
+ * is requested at much the same time as a wakeup event arrives, either
+ * the suspend will be interrupted, or it will complete quickly.
+ *
+ * The "little while" is a heuristic to avoid having to explicitly
+ * track every event through the kernel with associated locking and unlocking.
+ * It should be more than the longest time it can take between an interrupt
+ * occurring and the corresponding event being queued to userspace
+ * (and the accompanying kill_fasync call).
+ * This duration is configurable at boot time, has a lower limit of 2
+ * jiffies and an upper limit of 10 seconds. It defaults to the minimum.
+ */
+static unsigned long little_while_jiffies = 2;
+static in
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/1 James Bottomley : > On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote: >> On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley >> wrote: >> > On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote: >> >> On Tuesday 01 June 2010, James Bottomley wrote: >> >> > On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote: >> >> > > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: >> >> > > >> >> > > > You're the one mentioning x86, not me. I already explained that >> >> > > > some >> >> > > > MSM hardware (the G1 for example) has lower power consumption in S3 >> >> > > > (which I'm using as an ACPI shorthand for suspend to ram) than any >> >> > > > suspend from idle C state. The fact that current x86 hardware has >> >> > > > the >> >> > > > same problem may be true, but it's not entirely relevant. >> >> > > >> >> > > As long as you can set a wakeup timer, an S state is just a C state >> >> > > with >> >> > > side effects. The significant one is that entering an S state stops >> >> > > the >> >> > > process scheduler and any in-kernel timers. I don't think Google care >> >> > > at >> >> > > all about whether suspend is entered through an explicit transition or >> >> > > something hooked into cpuidle - the relevant issue is that they want >> >> > > to >> >> > > be able to express a set of constraints that lets them control whether >> >> > > or not the scheduler keeps on scheduling, and which doesn't let them >> >> > > lose wakeup events in the process. >> >> > >> >> > Exactly, so my understanding of where we currently are is: >> >> >> >> Thanks for the recap. >> >> >> >> > 1. pm_qos will be updated to be able to express the android suspend >> >> > blockers as interactivity constraints (exact name TBD, but >> >> > probably /dev/cpu_interactivity) >> >> >> >> I think that's not been decided yet precisely enough. I saw a few ideas >> >> here and there in the thread, but which of them are we going to follow? >> > >> > Well, android only needs two states (block and don't block), so that >> > gets translated as 2 s32 values (say 0 and INT_MAX). I've seen defines >> > like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to >> > describe these, but if all we're arguing over is the define name, that's >> > progress. >> >> I think we need separate state constraints for suspend and idle low >> power modes. On the msm platform only a subset of the interrupts can >> wake up from the low power mode, so we block the use if the low power >> mode from idle while other interrupts are enabled. We do not block >> suspend however if those interrupts are not marked as wakeup >> interrupts. Most constraints that prevent suspend are not hardware >> specific and should not prevent entering low power modes from idle. In >> other words we may need to prevent low power idle modes while allowing >> suspend, and we may need to prevent suspend while allowing low power >> idle modes. > > Well, as I said, pm_qos is s32 ... it's easy to make the constraint > ternary instead of binary. No, they have to be two separate constraints, otherwise a constraint to block suspend would override a constraint to block a low power idle mode or the other way around. > >> It would also be good to not have an implementation that gets slower >> and slower the more clients you have. With binary constraints this is >> trivial. > > Well, that's an implementation detail ... ordering the list or using a True. I think we also need timeout support in the short term though which is also somewhat simpler to implement in an efficient way for binary constraints. > btree would significantly fix that. However, the most number of > constraint users I've seen in android is around 60 ... that's not huge > from a kernel linear list perspective, so is this really a concern? ... > particularly when most uses don't necessarily change the constrain, so a > list search isn't done. The search is done every time any of them changes. > >> > The other piece they need is the suspend block name, which comes with >> > the stats API, and finally we need to decide what the actual constraint >> > is called (which is how the dev node gets its name) ... >> > >> >> > 2. pm_qos will be updated to be callable from atomic context >> >> > 3. pm_qos will be updated to export statistics initially closely >> >> > matching what suspend blockers provides (simple update of the rw >> >> > interface?) >> >> 4. It would be useful to change pm_qos_add_request to not allocate >> anything so can add constraints from init functions that currently >> cannot fail. > > Sure .. we do that for the delayed work queues, it's just an API which > takes the structure as an argument leaving it the responsibility of the > caller to free. > >> >> > After this is done, the current android suspend block patch becomes a >> >> > re-expression in kernel space in terms of pm_qos, with the current >> >> > userspace wakelocks bein
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 2010-06-01 at 19:45 -0700, mark gross wrote: > On Tue, Jun 01, 2010 at 04:01:25PM -0500, James Bottomley wrote: > > On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote: > > > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: > > > > > > > You're the one mentioning x86, not me. I already explained that some > > > > MSM hardware (the G1 for example) has lower power consumption in S3 > > > > (which I'm using as an ACPI shorthand for suspend to ram) than any > > > > suspend from idle C state. The fact that current x86 hardware has the > > > > same problem may be true, but it's not entirely relevant. > > > > > > As long as you can set a wakeup timer, an S state is just a C state with > > > side effects. The significant one is that entering an S state stops the > > > process scheduler and any in-kernel timers. I don't think Google care at > > > all about whether suspend is entered through an explicit transition or > > > something hooked into cpuidle - the relevant issue is that they want to > > > be able to express a set of constraints that lets them control whether > > > or not the scheduler keeps on scheduling, and which doesn't let them > > > lose wakeup events in the process. > > > > Exactly, so my understanding of where we currently are is: > > > > 1. pm_qos will be updated to be able to express the android suspend > > blockers as interactivity constraints (exact name TBD, but > > probably /dev/cpu_interactivity) > > 2. pm_qos will be updated to be callable from atomic context > > 3. pm_qos will be updated to export statistics initially closely > > matching what suspend blockers provides (simple update of the rw > > interface?) > > > > After this is done, the current android suspend block patch becomes a > > re-expression in kernel space in terms of pm_qos, with the current > > userspace wakelocks being adapted by the android framework into pm_qos > > requirements expressed to /dev/cpu_interactivity (or whatever name is > > chosen). Then opportunistic suspend is either a small add-on kernel > > patch they have in their tree to suspend when the interactivity > > constraint goes to NONE, or it could be done entirely by a userspace > > process. Long term this could migrate to the freezer and suspend from > > idle approach as the various problem timers get fixed. > > This is all nice but, all this does is implement the exact same thing as > the wake lock / suspend blocker API as a pm_qos request-class. funny that ... > It > leaves the overlapping constraint issue from ISR to user mode in place > depending on exactly how the oppertunistic suspend is implemented. if the vanilla kernel is simply consuming the pm_qos infrastructure and using suspend from idle, this is irrelevant. As I said, S3 suspend *can* be implemented via a suspend manager process from userspace (the alan stern proposal). However, if I were coding the android kernel, I'd do it as a tiny add on kernel patch. The main goal of making the android kernel close enough to the vanilla kernel for there not to be two separate upstreams for the device driver writers has been achieved regardless of which path is taken. > I expect it will be via a notifier on the pm_qos request-class update > that would do exactly what the wake lock code does today. just load up > an a "suspend_on_non_interactivity" driver that registers for the call > back, have it enabled by the user mode PM, and you have the equivelent > architecture as what was proposed by the wake lock patches. > > it gives the Android guys what they want, without adding a new > subsystem, minimizing the changes and makes most of the architecture > much more politicaly acceptible. > > But doesn't it have the same issues with getting the overlapping > constraints right from wake up source to user mode and dealing with the > wake up envents in a sane way? Instead of sprinkling suspend-blockers > about the kernel we'll sprinkle pm_qos_requests about. I like getting > more users of pm_qos, but isn't this the same thing? Suspend from idle doesn't have the wakeup problem. it only manifests if you want to take the system down via the S states. I think long term, making suspend from idle work for all hardware is the agreed goal, even if android can't implement it today and has to use an S state work around. > > I think the big unresolved issue is the stats extension. For android, > > we need just a name written along with the value, so we have something > > to hang the stats off ... current pm_qos userspace users just write a > > value, so the name would be optional. From the kernel, we probably just > > need an additional API that takes a stats name or NULL if none > > (pm_qos_add_request_named()?). Then reading the stats could be done by > > implementing a fops read routine on the misc device. > > I don't think the status would be a big deal to add. > > > However; I am really burned out by this
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote: > On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley > wrote: > > On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote: > >> On Tuesday 01 June 2010, James Bottomley wrote: > >> > On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote: > >> > > On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote: > >> > > > >> > > > You're the one mentioning x86, not me. I already explained that some > >> > > > MSM hardware (the G1 for example) has lower power consumption in S3 > >> > > > (which I'm using as an ACPI shorthand for suspend to ram) than any > >> > > > suspend from idle C state. The fact that current x86 hardware has > >> > > > the > >> > > > same problem may be true, but it's not entirely relevant. > >> > > > >> > > As long as you can set a wakeup timer, an S state is just a C state > >> > > with > >> > > side effects. The significant one is that entering an S state stops the > >> > > process scheduler and any in-kernel timers. I don't think Google care > >> > > at > >> > > all about whether suspend is entered through an explicit transition or > >> > > something hooked into cpuidle - the relevant issue is that they want to > >> > > be able to express a set of constraints that lets them control whether > >> > > or not the scheduler keeps on scheduling, and which doesn't let them > >> > > lose wakeup events in the process. > >> > > >> > Exactly, so my understanding of where we currently are is: > >> > >> Thanks for the recap. > >> > >> > 1. pm_qos will be updated to be able to express the android suspend > >> > blockers as interactivity constraints (exact name TBD, but > >> > probably /dev/cpu_interactivity) > >> > >> I think that's not been decided yet precisely enough. I saw a few ideas > >> here and there in the thread, but which of them are we going to follow? > > > > Well, android only needs two states (block and don't block), so that > > gets translated as 2 s32 values (say 0 and INT_MAX). I've seen defines > > like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to > > describe these, but if all we're arguing over is the define name, that's > > progress. > > I think we need separate state constraints for suspend and idle low > power modes. On the msm platform only a subset of the interrupts can > wake up from the low power mode, so we block the use if the low power > mode from idle while other interrupts are enabled. We do not block > suspend however if those interrupts are not marked as wakeup > interrupts. Most constraints that prevent suspend are not hardware > specific and should not prevent entering low power modes from idle. In > other words we may need to prevent low power idle modes while allowing > suspend, and we may need to prevent suspend while allowing low power > idle modes. Well, as I said, pm_qos is s32 ... it's easy to make the constraint ternary instead of binary. > It would also be good to not have an implementation that gets slower > and slower the more clients you have. With binary constraints this is > trivial. Well, that's an implementation detail ... ordering the list or using a btree would significantly fix that. However, the most number of constraint users I've seen in android is around 60 ... that's not huge from a kernel linear list perspective, so is this really a concern? ... particularly when most uses don't necessarily change the constrain, so a list search isn't done. > > The other piece they need is the suspend block name, which comes with > > the stats API, and finally we need to decide what the actual constraint > > is called (which is how the dev node gets its name) ... > > > >> > 2. pm_qos will be updated to be callable from atomic context > >> > 3. pm_qos will be updated to export statistics initially closely > >> > matching what suspend blockers provides (simple update of the rw > >> > interface?) > > 4. It would be useful to change pm_qos_add_request to not allocate > anything so can add constraints from init functions that currently > cannot fail. Sure .. we do that for the delayed work queues, it's just an API which takes the structure as an argument leaving it the responsibility of the caller to free. > >> > After this is done, the current android suspend block patch becomes a > >> > re-expression in kernel space in terms of pm_qos, with the current > >> > userspace wakelocks being adapted by the android framework into pm_qos > >> > requirements expressed to /dev/cpu_interactivity (or whatever name is > >> > chosen). Then opportunistic suspend is either a small add-on kernel > >> > patch they have in their tree to suspend when the interactivity > >> > constraint goes to NONE, or it could be done entirely by a userspace > >> > process. Long term this could migrate to the freezer and suspend from > >> > idle approach as the various problem timers get fixed. > >> > > >> > I think the big unresolved issue is the st
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
2010/6/1 Thomas Gleixner : > > On Mon, 31 May 2010, Arve Hjønnevåg wrote: > >> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner wrote: >> > On Mon, 31 May 2010, James Bottomley wrote: >> >> >> >> For MSM hardware, it looks possible to unify the S and C states by doing >> >> suspend to ram from idle but I'm not sure how much work that is. >> > >> > On ARM, it's not rocket science and we have in tree support for this >> > already (OMAP). I have done the same thing on a Samsung part as a >> > prove of concept two years ago and it's really easy as the hardware is >> > sane. Hint: It's designed for mobile devices :) >> > >> >> We already enter the same power state from idle and suspend on msm. In >> the absence of misbehaving apps, the difference in power consumption >> is entirely caused by periodic timers in the user-space framework >> _and_ kernel. It only takes a few timers triggering per second (I >> think 3 if they do no work) to double the average power consumption on >> the G1 if the radio is off. We originally added wakelocks because the >> hardware we had at the time had much lower power consumption in >> suspend then idle, but we still use suspend because it saves power. > > So how do you differentiate between timers which _should_ fire and > those you do not care about ? > Only alarms are allowed to fire while suspended. > We have mechanisms in place to defer timers so the wakeups are > minimized. If that's not enough we need to revisit. > Deferring the the timers forever without stopping the clock can cause problems. Our user space code has a lot of timeouts that will trigger an error if an app does not respond in time. Freezing everything and stopping the clock while suspended is a lot simpler than trying to stop individual timers and processes from running. -- 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
