Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/