From: Rafael J. Wysocki on
On Thursday 27 May 2010, Peter Zijlstra wrote:
> On Thu, 2010-05-27 at 13:29 -0400, Alan Stern wrote:
> >
> > They may be different conceptually. Nevertheless, Android uses forced
> > suspend as a form of power saving. Until better mechanisms are in
> > place, it makes sense.
>
> So let them, doesn't mean we have to merge it. Or will you saw your foot
> off too if google were to promotes it?

Do you have to be offensive to people who disagree with you?

Alan simply wants to understand the _technical_ objections that people have
to this patchset and you're not helping. So, could you please explain what
exactly is your technical objection to it?

Rafael
--
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
> That's the point -- suspend does not evaluate the system state
> correctly because it doesn't have the necessary information. Suspend

The power management layer knows if the machine is idle, it has insight
into when the next wakeups will occur.

> blockers are a way of providing it that information. They don't paper
> over the problem; they solve it.

I'm still unconvinced (see Thomas examples as a starter) and even if they
did, the cure would be far worse than the disease.

The hardware world also shows how you handle suspend/resume event races
cleanly and in turn how we can handle right from user to hardware.

If you are dealing with a well behaved UI app then its event loop will
just do

if (message == UI_OFF) {
stop_background_stuff();
event_mask &= stuff;
send_reply(NIGHT_NIGHT);
continue;
/* Back to poll() */
}

and power management does the rest. If an event wakes up the process
before we get to suspend in kernel we will wake it back up. If the event
gets in after pm decides to idle via suspend then it'll bounce through
the kernel back to a kernel resume, or potentially through a full
hardware/software suspend/resume bounce. You have one person who needs to
track the sequence - that's however is the guy sending UI_ON/UI_OFF
information and making the screen light up.

If you are dealing with a badly behaved app then you can't win because it
may not have the magic 'suspend blockers' or will do it wrong. You
can constrain it (brute force SIGSTOP after it refuses to UI_OFF for a
bit, or via nice or other QoS policy) but you can't assume it'll
magically managge itself. It is "badly behaved" so by that very
definition you can't assume it has correct magic goo in it. (Side note:
the extra magic goo and complexity of such blockers makes it more likely
the app will be buggy and thus 'badly behaved' !)

You can pick up which tasks are stopping the suspend fairly easily at the
moment via the ktrace interfaces. Maybe there is a case for making that
tidier but powertop and the like already demonstrate you can track this.

A cpu policy can obviously expose offenders itself directly to user
space. That (and indeed people not responding to UI_OFF) then lets your
phone do

<boop>
X is misbehaving
[Close it] [Allow this time] [Disable]

and also to provide stats for each wakeup a policy manager can spot
offenders (even those who are perhaps hard to see because they wake up a
little bit every so often but just enough to mess up pm). In the x86
world Arjan found a *lot* of that sort of stuff.

Your policy manager can also act on it. The current policy manager is
to fix app bugs and shows people up at conferences. I would imagine a
google policy would be to collate misbehaving app reports at google.com
and use them both to assist in 'educating' authors and in scoring app
store stuff.

As it is <boop> X is misbehaving is a powerful economic lever in a
pretty dynamic and functioning software market.

Google seem to be pretty good at statistical data, I can't believe
battery advice for apps on the app stores and indeed a 'where did my
battery go' pie chart are beyond their wit, or beyond the end user to
figure out.

There are a considerable number of people shipping power constrained
Linux devices without suddenely desperately needing extra magic potions.
Are they really all just that much smarter than Google ?

Alan
--
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 05:24:28PM -0400, Alan Stern wrote:

> Would it help to divide the application into two processes, one of
> which receives events and the other does the drawing?

At the point where you're rewriting the application you can just make it
adhere to our current behavioural standards anyway.

--
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 Cox on
On Thu, 27 May 2010 13:29:18 -0400 (EDT)
Alan Stern <stern(a)rowland.harvard.edu> wrote:

> On Thu, 27 May 2010, Peter Zijlstra wrote:
>
> > On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote:
> > >
> > > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > > should be removed? Or "echo disk >/sys/power/state"? They pay no
> > > attention to latencies or other requirements.
> >
> > Those are a whole different beast, those are basically a quick-off
> > button like thing. Forced suspend is conceptually a very different beast
> > from power-saving a running system.
>
> They may be different conceptually. Nevertheless, Android uses forced
> suspend as a form of power saving. Until better mechanisms are in
> place, it makes sense.

For them, not for Linux.

Several vendors have exciting kernel drivers that do things like binary
patch other modules. Until better mechanisms are in place it does *NOT*
make sense to merge such stuff.

I don't care what they do in their own tree (consenting adults in their
own home and all that) but what they do in the public tree is another
matter.

Alan
--
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:

> > > Doesn't help - I may be hit by the signal between the poll() unblocking
> > > and me having the opportunity to call sigmask().
> >
> > ppoll(). This is all existing solved stuff.
>
> Isn't that the inverse of what we want? The application should default
> to being SIGSTOPpable except in the case of it being in the process of
> having a specific event delivered.

Would it help to divide the application into two processes, one of
which receives events and the other does the drawing?

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/