On Fri, May 28, 2010 at 7:21 AM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > On Fri, May 28, 2010 at 05:14:31PM +0300, Igor Stoppa wrote: > >> I have seen very good proposals for saner solutions. >> >> Is that progress? > > The proposals so far involve either redefining the problem space or > being inherently racey. It may be that we can redefine the problem space > in such a way that everyone's happy, but it's not possible to do so by > fiat. I think the suggestion that has the closet fit with what we're trying to accomplish is Ingo's (or perhaps Ingo's explanation of Alan's): http://lkml.org/lkml/2010/5/28/106 where it's implemented as a constraint of some sort. Arve points out that qos constraint objects could work (but not if specifically tied to apps): http://lkml.org/lkml/2010/5/28/120 though he suggests that "latency" constraints don't represent this as well as "state" constraints. Though if you look at it that way, then suspend_blockers become qos constraint objects, but their implementation and usage remain pretty much the same as we have now, which does not address Alan's concern regarding code turning up in drivers, etc. I'm not sure how you can solve this problem (avoiding races around entering/exiting the suspend or suspend-like state) without having a means for drivers to prevent entry to that state. I need to think more about the cgroups approach, but I'm pretty sure it still suffers from wakeup race situations, and due to the complexity of userspace (at least ours), I suspect it would risk livelock/deadlock/priority-inversion style issues due to interaction between different processes in different groups. Brian _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
