From: Matthew Garrett on
On Thu, May 27, 2010 at 08:53:11PM +0200, Thomas Gleixner wrote:
> On Thu, 27 May 2010, Matthew Garrett wrote:
> > We were talking about PCs. Suspend-as-c-state is already implemented for
> > OMAP.
>
> Ah, now we talk about PCs. And all of a sudden the problem of the
> unability of determining wakeup sources is not longer relevant ? So
> how do you guarantee that we don't miss one if we cant figure out
> which ones are kept alive in S3 ?

A wakeup event is defined as one that wakes the system - if a system
can't be woken by a specific event then it's impossible to lose it,
since it wasn't a wakeup event to begin with.

> > > So the only thing you are imposing to app writers is to use an
> > > interface which solves nothing and does not save you any power at
> > > all.
> >
> > It's already been demonstrated that the Android approach saves power.
>
> Demonstrated ? Care to explain me how it makes a difference:
>
> while (1) {
> block();
> read();
> process_event();
> unblock();
> ---> suspend
> <--- resume
> do_crap(); 1000000 cycles
> }
>
> vs.
>
> while (1) {
> read();
> ---> suspend
> <--- resume
> process_event();
> do_crap(); 1000000 cycles
> }
>
> You spend the damned 10000000 cycles in any case just at a different
> point in time. So if you are so convinced and have fully understood
> all the implications, please enlighten me why do_crap() costs less
> power with the blockers approach.

Consider the case where the read() is non-blocking.

> 1) The kernel blocker does not guarantee that the lousy app has
> processed the event. It just guarantees that the lousy app has
> emptied the input queue. So what's the point of the kernel blocker
> in that case ?

Yes, I think you're right here. You need the userspace component as well
for this to work correctly.

> 2) What's the difference on setting that app to QoS(NONE) and let the
> kernel happily ignore it.

What sets that flag, and how does it interact with an application that
never makes a blocking system call?

> Come up with real explanations and numbers and not just the "it has
> been demonstrated" chant which is not holding water if you look at the
> above.

The numbers were earlier in the thread.

> The kernel history is full of examples where crappy solutions got
> rejected and kept out of the kernel for a long time even if there was
> a need for them in the application field and they got shipped in
> quantities with out of tree patches (NOHZ, high resolution timers,
> ...). At some point people stopped arguing for crappy solutions and
> sat down and got it right. The problem of power management and
> opportunistic suspend is not different in any way.

Yes, and I'd agree with this if anyone seemed to have any idea how to do
it right. But despite all the heat and noise in this thread, all we've
got is an expression that it should be handled by the scheduler (a
viewpoint I agree with) without any explanation of how to switch
policies in such a way that applications idle without losing wakeup
events.

--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on
On Thu, 27 May 2010, Matthew Garrett wrote:

> On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
>
> > Shall we henceforth stop confusing forced suspend for laptops and
> > powersaving a running system?
>
> If you want to support forced suspend for laptops and you want to avoid
> the risk of losing wakeups then you need in-kernel suspend blockers.
> That's entirely orthogonal to Android's runtime power management.

Rather than continue going around in circles, let's agree that what the
Android people want is a new version of forced suspend -- not a
power-saving idle mode. As such, latency is simply not relevant.

Here's an idea for a new approach that avoids the need for in-kernel
suspend blockers. I don't know exactly how or if it can be made to
work, but at least it's a different way of looking at the problem.

A normal forced suspend is unconditional: It stops the system no matter
what is happening. The Android people want to make it conditional:
Don't stop the system until nothing "important" is happening.

So what is "important"? A possible definition could go like this.
Let's add a per-process (or per-thread) flag to mark "important"
processes. And let's say that a process with this flag set is doing
"important" work unless it is blocked inside a poll() system call.

Given that definition, an opportunistic suspend is a forced suspend
that waits until no important processes are doing important work (i.e.,
all important processes are stuck inside poll).

Is this adequate to meet Android's needs? I don't know. It can handle
the case of a program waiting for a keystroke or network packet to
arrive.

Does it allow for sufficient accounting statistics and debugging
capability? I don't know -- no doubt this depends on how it is
implemented.

Can it be made to work? I don't know -- in fact, I don't even know how
the poll() system call works internally. Certainly there is one
complication that needs to be handled: While a suspend is underway, the
important processes will be frozen and hence not sitting inside the
poll() call. If an event occurs that normally would cause the poll to
complete, we would need to make it abort the suspend. But it's
difficult to detect when this happens. It may be necessary to _avoid_
freezing the important processes in order for this to work.

The advantages:

No more suspend blockers cluttering up random drivers all over
the kernel. All the work is centralized in the poll()
routines and the PM core.

It is driven by userspace policy (which processes to mark as
"important") rather than kernel choice.

Is this doable? Is it worth doing? Is it better than using suspend
blockers?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on
> > If one works so does the other.
>
> Not at all. The entire point of opportunistic suspend is that I don't
> care is currently in TASK_RUNNABLE or has a timer that's due to expire
> in 100msec - based on policy (through not having any held suspend
> blockers), I'll go to sleep. That's easily possible on PCs.

Yes I appreciate what suspend blockers are trying to do. Now how does
that connect with my first sentence ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on
> The problem is determining how to constrain it to go idle, where "idle"
> is defined as "Doesn't wake up until a wakeup event is received". It's
> acceptable for something to use as much CPU as it wants when the user is
> actively interacting with the device, but in most cases processes
> shouldn't be permitted to use any CPU when the session is idle. The
> question is how to implement something that allows a CPU-guzzling
> application to be idled without impairing its ability to process wakeup
> events.

From your literal description:

setpriority. signal, process groups.

kill(-desktopgroup, SIGSTOP);
kill(-desktopgroup, SIGCONT);
kill(pid_i_am_crit_eventing, SIGCONT);

or SIGTSTP might be friendlier as a well behaved smart app can catch it,
fire it into the event loop and elegantly save and sleep.

Some window managers played with doing setpriority for focussed windows.
OLPC the same thing for OOM targets via /proc/oom_adj

The scheduler can happily do this, the power management will also
recognize STOPPED processes as no impediment to suspend.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on
On Thu, May 27, 2010 at 08:03:13PM +0100, Alan Cox wrote:
> > No, it's not. Forced suspend may be in response to hitting a key, but it
>
> You are the only person here talking about 'forced' suspends. The rest of
> us are talking about idling down and ensuring we are always in a state we
> un-idle correctly.

Sigh. No. Forced suspend is a fact of life, and suspend blockers improve
the ability to support it. It's orthogonal to more general runtime PM.

> > may also be in response to a 30 minute timeout expiring. If I get a WoL
> > packet in the 0.5 of a second between userspace deciding to suspend and
> > actually doing so, the system shouldn't suspend.
>
> I don't think that argument holds water in the form you have it
>
> What about 5 nanoseconds before you suspend. Now you can't do that (laws
> of physics and stuff).

Drivers should enable wakeups before they disable interrupts. So either
the packet hits the IRQ handler and the driver takes a suspend block
(aborting suspend in the process) or it doesn't, the GPE goes high and
the system resumes immediately after entering S3.

> Set wake flags
> Check if idle
> If idle
> Suspend
> else
> Clear wake flags
> Unwind
>
> and the wake flags guarantee that an event at any point after the wake
> flags are set until they are cleared will cause a suspend to be resumed,
> possibly immediately after the suspend.

Exactly. So the 5 nanosecond case is already handled. The interesting
case is where userspace makes the decision to go to sleep and starts
performing various housekeeping tasks before triggering the suspend. You
need some way to abort that suspend. The hardware may be long idle by
then, so you can't just look at the hardware state.

--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/