On Sunday 06 June 2010, Arve Hjønnevåg wrote: > 2010/6/5 Rafael J. Wysocki <rjw@xxxxxxx>: > > On Sunday 06 June 2010, Arve Hjønnevåg wrote: > >> 2010/6/5 Rafael J. Wysocki <rjw@xxxxxxx>: > >> > On Saturday 05 June 2010, Arve Hjønnevåg wrote: > >> >> 2010/6/4 Matt Helsley <matthltc@xxxxxxxxxx>: > >> >> > 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@xxxxxxxxxxxxx> wrote: > >> >> >> > On Sat, 5 Jun 2010, Rafael J. Wysocki wrote: > >> >> > > >> >> > <snip> > >> >> > > >> >> >> > >> >> >> > With the cgroup freezer you can "suspend" them right away and > >> >> >> > just keep the trusted background task(s) alive which allows us to > >> >> >> > go into deeper idle states instead of letting the crapplications > >> >> >> > run unconfined until the download finished and the suspend > >> >> >> > blocker goes away. > >> >> >> > > >> >> >> > >> >> >> Yes this would be better, but I want it in addition to suspend, not > >> >> >> instead of it. It is also unclear if our user-space code could easily > >> >> >> make use of it since our trusted code calls into untrusted code. > >> >> >> > >> >> > > >> >> > Perhaps I'm misunderstanding, but suspend and the cgroup freezer > >> >> > interoperate well today -- you don't have to choose one or the other. > >> >> > If you've discovered otherwise I'd consider it a bug and would like to > >> >> > hear more about it. > >> >> > > >> >> > >> >> I'm not aware of any bug with combining both, but we cannot use > >> >> suspend at all without suspend blockers in the kernel (since wakeup > >> >> events may be ignored) > >> > > >> > The more I think of it, the more it appears to me that the problem of > >> > lost wakeup events can actually be solved without suspend blockers. > >> > I'll send a bunch of patches to address this issue, probably tomorrow. > >> > > >> > >> I know of two ways to prevent lost wakeup events. Reset a timeout > >> every time you receive a wakeup event or prevents suspend until you > >> know the event has been fully processed. Does your solution fall onto > >> one of these two categories, or do you have a third way? > > > > Basically, it involves two mechanisms, detection of wakeup events occuring > > right before suspend is started > > This sounds like the timeout approach which I thought you did not like. > > > and aborting suspend if wakeup events occur > > in the middle of it. > > > Aborting suspend is easy, but when do you allow suspend again? I would recommend you to wait for the patches and then comment. :-) > >> >> and I don't know how we can safely freeze > >> >> cgroups without funneling all potential wakeup events through a > >> >> process that never gets frozen. > >> > > >> > If your untrusted apps get called by the trusted ones, they aren't really > >> > untrusted in the first place. > >> > > >> That is not a correct statement. A trusted apps can call into an > >> untrusted app, it just has to validate the response and handle not > >> getting a response at all. There are also different levels of trust. I > >> may have trusted an app to provide a contact pictures, but not trusted > >> it to block suspend. When the phone rings the app will be called to > >> provide the picture for the incoming call dialog, but if it is frozen > >> at this point the more trusted app that handles the incoming phone > >> call will not be able to get the picture. > > > > It will be able to do that if it causes the frozen part of user space to be > > thawed. > > > > I think you have this problem already, though, because you use full system > > suspend and all of your apps are frozen by it. So, to handle the situation you > > describe above, you need to carry out full system resume that will thaw the > > tasks for you. I don't see any fundamental difference betwee the two cases. > > > > Yes, we can keep all our user space suspend blockers and thaw the > frozen cgroup when any suspend blocker is held, but this would > eliminate any power advantage that freezing a cgroup has over using > suspend to freeze all processes. Why does it have to have _any_ power advantage? It's totally sufficient if it gives you approximately the same power savings. IOW, it doesn't have to be _better_ if it's acceptable to the kernel people at large. The rest of your objections have been addressed by Alan, so I'm not going to repeat his arguments. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
