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

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> 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