From: Tony Lindgren on
* Matthew Garrett <mjg(a)redhat.com> [100513 14:16]:
> On Thu, May 13, 2010 at 02:10:06PM -0700, Tony Lindgren wrote:
> > * Matthew Garrett <mjg(a)redhat.com> [100513 13:29]:
> > > And if that's the application that's listening to the network socket
> > > that you want to get a wakeup event from? This problem is hard. I'd love
> > > there to be an elegant solution based on using the scheduler, but I
> > > really don't know what it is.
> >
> > Your system should wake up to an interrupt in that case. Then you have
> > the trusted apps running that can decide if the untrusted apps should
> > be continued or not.
>
> What race-free mechanism do you use to ensure that? It's very easy to
> handwave these problems away. It's very difficult to actually write an
> implementation that works.

Can you describe where do you see the race now?

Your trusted apps should be have in quite a normal way except the system
suspends if no critical timers are on the list. For the untrusted apps
you assume you can stop them at whatever userspace policy you set.

Regards,

Tony
--
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, 13 May 2010, Tony Lindgren wrote:

> * Alan Stern <stern(a)rowland.harvard.edu> [100513 07:11]:
> > On Wed, 12 May 2010, Paul Walmsley wrote:
> >
> > > Hello,
> > >
> > > Some general comments on the suspend blockers/wakelock/opportunistic
> > > suspend v6 patch series, posted here:
> > >
> > > https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html
> > >
> > > The comments below are somewhat telegraphic in the interests of
> > > readability - more specific comments to follow in later E-mails. I am
> > > indebted to those of us who discussed these issues at LPC last year and
> > > ELC this year for several stimulating discussions.
> > >
> > > There are several general problems with the design of opportunistic
> > > suspend and suspend-blocks.
> > >
> > > 1. The opportunistic suspend code bypasses existing Linux kernel code,
> > > such as timers and the scheduler, that indicates when code
> > > needs to run, and when the system is idle.
> >
> > Whoa! That's not my understanding at all.
> >
> > As I see it, opportunistic suspend doesn't bypass any code that isn't
> > already bypassed by the existing suspend code. Users can do
> >
> > echo mem >/sys/power/state
> >
> > whenever they want, without regard to kernel timers and the scheduler
> > (other than the fact that the user's thread must be running in order to
> > carry out the write, of course).
>
> The difference between echo mem > /sys/power/state and suspend blocks
> is that with suspend blocks the system keeps running.

Irrelevant. Paul wasn't talking about the suspend blockers; he was
talking about opportunistic suspend. So what's the difference between
opportunistic suspend and "echo mem >/sys/power/state"? Especially
when suspend blockers aren't being used?

> And that's why
> it should be handled by runtime power management instead.

Runtime PM is not capable of freezing userspace and shutting down CPUs.
More or less by definition -- if it could then it wouldn't be "runtime"
any more, since the processor wouldn't be running.

> The suspend blocks seems like a hack to spam filter good and bad
> apps from timer usage point of view. Applications are categorized
> as good or bad depending if they grab a susped blocker or not.

You're referring just to the userspace part of the suspend blocker
API. What about the kernel part?

> I believe categorizing the apps should be instead done with some
> timer flags or cgroups instead.

That would be compatible with 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: Daniel Walker on
On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote:

> Because someone would have to remove suspend blockers (or rather wakelocks)
> from the drivers, test that they work correctly without suspend blockers and
> submit the modified versions. Going forward, every party responsible for such
> a driver would have to maintain an out-of-tree version with suspend blockers
> (or wakelocks) anyway, so the incentive to do that is zero.

They should work without wakelock since wakelock are optional .. I mean
there's nothing in suspend blockers I've seen that indicates it's
required for some drivers to work. So it's just a matter of patching out
the wakelocks, with no need to re-test anything.

You get the driver mainlined, then maintain a small patch to add
wakelocks. Not hard at all , with lots of incentive to do so since you
don't have to maintain such a large block of code out of tree.

> Practically, as long as the opportunistic suspend is out of tree, there will be
> a _growing_ number of out-of-tree drivers out there, which is not acceptable
> in the long run.

I don't see why your saying that. These driver should work with out all
of this, which means they can get mainlined right now.

Daniel

--
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, 13 May 2010, Tony Lindgren wrote:

> Well this is an interesting problem, and once solved will be handy
> for all kind of things. My worry is that if it's integrated in it's
> current form it will be totally out of control all over the place :(
>
> Still hoping we can come up with some clean way that avoid the patching
> all over the place part.. How about the following, can you please check
> if it would help with your example of guaranteed handling of event:
>
> 1. In the kernel, we add one more timer queue for critical timers.
> The current timer queue(s) stay as it is.
>
> 2. We allow selecting the timer based on some flag, the default
> behaviour being the current default timer queue.
>
> 3. Then we add next_timer_interupt_critical() to only query the
> critical timers along the lines of the current next_timer_interrupt().
>
> 4. We implement a custom pm_idle that suspends the system based on
> some logic and checking if next_timer_interrupt_critical() is
> empty. If the next_timer_interrupt_critical() does not return
> anything, we assume it's OK to suspend the system.
>
> Now to me it sounds if your the input layer and userspace handle
> both grab the timers with the critical flags, it should be guaranteed
> that the events get handled before the system is suspended.

Why do you want this to be tied to timers? Many of the events in
question are asynchronous with no specific timing relations.

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: Tony Lindgren on
* Alan Stern <stern(a)rowland.harvard.edu> [100513 14:32]:
> On Thu, 13 May 2010, Tony Lindgren wrote:
>
> > The difference between echo mem > /sys/power/state and suspend blocks
> > is that with suspend blocks the system keeps running.
>
> Irrelevant. Paul wasn't talking about the suspend blockers; he was
> talking about opportunistic suspend. So what's the difference between
> opportunistic suspend and "echo mem >/sys/power/state"? Especially
> when suspend blockers aren't being used?

Opportunistic suspend is really trying to do runtime PM, see below.

> > And that's why
> > it should be handled by runtime power management instead.
>
> Runtime PM is not capable of freezing userspace and shutting down CPUs.
> More or less by definition -- if it could then it wouldn't be "runtime"
> any more, since the processor wouldn't be running.

Not true. We are already powering off CPUs and rebooting them for
at least omaps in every idle loop using cpuidle. The memory stays on.

> > The suspend blocks seems like a hack to spam filter good and bad
> > apps from timer usage point of view. Applications are categorized
> > as good or bad depending if they grab a susped blocker or not.
>
> You're referring just to the userspace part of the suspend blocker
> API. What about the kernel part?

IMHO some timer flags should be used in the kernel too. Currently
there's no way of knowing which timers are good or bad from suspend
point of view.

Regards,

Tony
--
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/