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. > 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. >From what you're saying it follows that you're not really willing to accept any solution different to your suspend blockers. Is that really the case? 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
