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

Alan Cox
2010-05-27T16:16:15Z

> No. Suspend blockers are designed to ensure that suspend isn't racy with
> respect to wakeup events. The bit that mitigates badly written
> applications is the bit where the scheduler doesn't run any more.

How does having applications taking blockers fix that - it makes it
worse. They are now blocking the kernel doing the right job.

> If you're happy with a single badly written application being able to
> cripple your power management story, you don't need opportunistic

And taking a suspend blocker isn't "crippling your power management" ???

> What /is/ the correct way to solve this problem when entering explicit
> suspend states? How do you guarantee that an event has been delivered to
> userspace before transitioning into suspend? Now, this is a less
> interesting problem if you're not using opportunistic suspend, but it's
> still a problem.

The same way as we deal with low power states on other non PC devices ?

> That's no good. If the input device has been deactivated, how does the
> wakeup event get delivered to the application?

If the input device is letting itself get de-activated in a way that can
lose events the input device driver is buggy. It's nobody elses business
how it does the its job, and certainly *not* the applications.

That's a kernel internal issue.

You know the resource constraint exists because the driver knows it is
open
Your QoS guarantees tell you what you desired latency of response at the
point you can become ready is.

That's all your need to do it right.

In kernel yes your device driver probably does need to say things like
'Don't go below C6 for a moment' just as a high speed serial port might
want to say 'Nothing over 10mS please'

I can't speak for Thomas, but I'm certainly not arguing that you don't
need something that looks more like the blocker side of the logic *in
kernel*, because there is stuff that you want to express which isn't tied
to the task.

So you need

Userspace -> QoS guarantee expression, implied resource
expression via device use. *NO* knowledge of
device or platform in the application

Kernel space

Drivers -> Explicit guarantee expression not bound to
tasks. Driver encapsulates the variety in the
device hardware and expresses it in a uniform
manner to the idling/suspend logic

CPU Freq -> Encapsulates the variety in the CPU and core
power functionality of devices, makes policy
based upon the uniform express from the drivers
and tasks

All the autonomy is now in the right places, and we have requisite variety
to actually manage the situation.

Alan