suspend blockers & Android integration
in [Kernel]
|
Prev: How do I ignore the changes made by CVS keyword substitution efficiently?
Next: [PATCH 1/2] x86: make save_stack_address() !CONFIG_FRAME_POINTER friendly
From: Felipe Contreras on 6 Jun 2010 07:20 2010/6/6 <david(a)lang.hm>: > On Sun, 6 Jun 2010, Brian Swetland wrote: > if you could shrink the time awake to 0.01 second per wakeup you would shift > this all up a category (and avoiding the need to wake everything up to > service a timer would help do this) > > this effort very definantly has diminishing returns as you go to larger > sleep periods as the constant standby power draw becomes more and more > dominating. someone mentioned that they were getting the sleep time of > normal systems up past the 1 second mark with the 10 second mark looking > very attainable. that is where you get the most benifit for whatever changes > are needed. getting up to a 2 min sleep time really gives you about all the > benifit that you can get, going from there to 15 min makes very little > difference. > > don't let chasing the best possible sleep time prevent you from considering > options that would be good enough in time, but would drastically reduce the > maintinance effort (as things could be upstreamed more easily), and would be > usable on far more systems. Not to mention the fact that there's nothing fundamental that prevents dynamic PM to reach > 15 min idle. It's a matter of time before we find the tools needed. The amount of work that suspend blockers would require to implement properly in user-space other than Android just doesn't match the power savings. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 6 Jun 2010 09:30 On Sunday 06 June 2010, Arve Hj�nnev�g wrote: > 2010/6/5 Rafael J. Wysocki <rjw(a)sisk.pl>: > > On Sunday 06 June 2010, Arve Hj�nnev�g wrote: > >> 2010/6/5 Rafael J. Wysocki <rjw(a)sisk.pl>: > >> > On Saturday 05 June 2010, Arve Hj�nnev�g wrote: > >> >> 2010/6/4 Matt Helsley <matthltc(a)us.ibm.com>: > >> >> > On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hj�nnev�g wrote: > >> >> >> On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner <tglx(a)linutronix.de> wrote: > >> >> >> > On Sat, 5 Jun 2010, Rafael J. Wysocki wrote: > >> >> > > >> >> > <snip> > >> >> > > >> >> >> > >> >> >> > With the cgroup freezer you can "suspend" them right away and > >> >> >> > just keep the trusted background task(s) alive which allows us to > >> >> >> > go into deeper idle states instead of letting the crapplications > >> >> >> > run unconfined until the download finished and the suspend > >> >> >> > blocker goes away. > >> >> >> > > >> >> >> > >> >> >> Yes this would be better, but I want it in addition to suspend, not > >> >> >> instead of it. It is also unclear if our user-space code could easily > >> >> >> make use of it since our trusted code calls into untrusted code. > >> >> >> > >> >> > > >> >> > Perhaps I'm misunderstanding, but suspend and the cgroup freezer > >> >> > interoperate well today -- you don't have to choose one or the other. > >> >> > If you've discovered otherwise I'd consider it a bug and would like to > >> >> > hear more about it. > >> >> > > >> >> > >> >> I'm not aware of any bug with combining both, but we cannot use > >> >> suspend at all without suspend blockers in the kernel (since wakeup > >> >> events may be ignored) > >> > > >> > The more I think of it, the more it appears to me that the problem of > >> > lost wakeup events can actually be solved without suspend blockers. > >> > I'll send a bunch of patches to address this issue, probably tomorrow. > >> > > >> > >> I know of two ways to prevent lost wakeup events. Reset a timeout > >> every time you receive a wakeup event or prevents suspend until you > >> know the event has been fully processed. Does your solution fall onto > >> one of these two categories, or do you have a third way? > > > > Basically, it involves two mechanisms, detection of wakeup events occuring > > right before suspend is started > > This sounds like the timeout approach which I thought you did not like. > > > and aborting suspend if wakeup events occur > > in the middle of it. > > > Aborting suspend is easy, but when do you allow suspend again? I would recommend you to wait for the patches and then comment. :-) > >> >> and I don't know how we can safely freeze > >> >> cgroups without funneling all potential wakeup events through a > >> >> process that never gets frozen. > >> > > >> > If your untrusted apps get called by the trusted ones, they aren't really > >> > untrusted in the first place. > >> > > >> That is not a correct statement. A trusted apps can call into an > >> untrusted app, it just has to validate the response and handle not > >> getting a response at all. There are also different levels of trust. I > >> may have trusted an app to provide a contact pictures, but not trusted > >> it to block suspend. When the phone rings the app will be called to > >> provide the picture for the incoming call dialog, but if it is frozen > >> at this point the more trusted app that handles the incoming phone > >> call will not be able to get the picture. > > > > It will be able to do that if it causes the frozen part of user space to be > > thawed. > > > > I think you have this problem already, though, because you use full system > > suspend and all of your apps are frozen by it. So, to handle the situation you > > describe above, you need to carry out full system resume that will thaw the > > tasks for you. I don't see any fundamental difference betwee the two cases. > > > > Yes, we can keep all our user space suspend blockers and thaw the > frozen cgroup when any suspend blocker is held, but this would > eliminate any power advantage that freezing a cgroup has over using > suspend to freeze all processes. Why does it have to have _any_ power advantage? It's totally sufficient if it gives you approximately the same power savings. IOW, it doesn't have to be _better_ if it's acceptable to the kernel people at large. The rest of your objections have been addressed by Alan, so I'm not going to repeat his arguments. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 6 Jun 2010 09:40 On Sun, Jun 06, 2010 at 12:05:57PM +0100, Alan Cox wrote: > On Sun, 6 Jun 2010 12:46:01 +0200 > Florian Mickler <florian(a)mickler.org> wrote: > > That is not true. While the kernel is not suspended it does > > runtime pm. > > On several of our platforms runtime PM already includes suspend so a > suspend wakelock does interfere with existing power managemet at that > level (not to mention the maintenance mess it causes). No, it doesn't. Android on omap will enter the mpu/core off state from the idle loop even if a suspend block is held. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 6 Jun 2010 09:40 On Sun, Jun 06, 2010 at 12:00:47PM +0200, Vitaly Wool wrote: > Sure, but my point was, some non-trivial (still kind of natural for a > smartphone) activities with the device will prevent it from suspending > for quite some time. Even worse, the suspend wakelock will keep the > whole kernel active, as opposed to powering off unused devices > separately as it's done in runtime PM. Yep, I know about the "early > suspend" type of thing; yet it's excess, not mainlined and lacks > granularity. Holding a suspend blocker is entirely orthogonal to runtime pm. The "whole kernel" will not be "active" - it can continue to hit the same low power state in the idle loop, and any runtime pm implementation in the drivers will continue to be active. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 6 Jun 2010 10:00
On Sunday 06 June 2010, Arve Hj�nnev�g wrote: > 2010/6/5 Rafael J. Wysocki <rjw(a)sisk.pl>: > > On Saturday 05 June 2010, Arve Hj�nnev�g wrote: > >> 2010/6/5 Thomas Gleixner <tglx(a)linutronix.de>: > >> > B1;2005;0cOn Fri, 4 Jun 2010, Arve Hj�nnev�g wrote: .... > > > > Arve, we're still learning you have some more requirements we had no idea > > What new requirement are you talking about. Did you assume all our > user-space ipc calls went though a single process? No, but I didn't assume that your wakelock-holding processes depend on the other processes in a way that might prevent them from acquiring or dropping a wakelock. .... > >> >> Trusted code that calls into untrusted code has to deal with the > >> >> untrusted code not responding, but we only want to pop up a message > >> >> that the application is not responding if it is misbehaving, not just > >> >> because it was frozen though no fault of its own. > > > > When Android starts opportunistic suspend, all applications are frozen, > > "trusted" as well as "untrusted", right? So, after they are all frozen, none > > of them can do anything to prevent suspend from happening, right? > > Not if you mean when we write to /sys/power/state. Processes are not > frozen until the last suspend blocker is released. That doesn't matter. In the opportunistic mode you don't need to write into /sys/power/state to start suspend, this is done by the kernel automatically as soon as the last wakelock has been released (at least this is my assumption about how this works). Now, at this point the processes that don't use wakelocks can't really prevent themselves from being frozen and only the wakelocks users can do that. So, if a wakelock user depends on a process that doesn't use wakelocks in such a way that (because of that dependence) it can't acquire its wakelock while processes are being frozen, things don't work as they are supposed to. > > Now, in my proposed approach the "untrusted" apps are frozen exactly at the > > point Android would start opportunistic suspend and they wouldn't be able > > to do anything about that anyway. So if one of your "trusted" apps depends > > on the "untrusted" ones in a way that you describe, you alread have a bug > > (the "trusted" app cannot prevent automatic suspend from happening even if it > > wants, because it depends on an "untrusted" app that has just been frozen). > > > > I don't think what you said here is correct. If a wakeup event happens > all processed are unfrozen since the driver blocks suspend. This only means that the theoretical failure you gave as an example doesn't happen in practice. No problem, then. :-) > The app that reads this event blocks suspend before reading it. If it was > busy talking to a less trusted app when the event happened it still works > since all apps are running at this point. And how is this different from an approach with cgroup freezing? Apps that use wakelock within the current framework would use "freeze locks" to prevent the "untrusted" part of user space from being frozen or to thaw it. Where's the problem, then? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |