From: Tony Lindgren on
* 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. And that's why
it should be handled by runtime power management instead.

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.

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

Cheers,

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: Matthew Garrett on
On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote:
> 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.
>
> I believe categorizing the apps should be instead done with some
> timer flags or cgroups instead.

I agree, but we have no mechanism for implementing that in a race-free
way. We don't even have a realistical proposal for what that mechanism
would look like. Should we refuse bread today for the promise of cake
tomorrow?

--
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: Daniel Walker on
On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote:
> On Thu, May 13, 2010 at 11:59:37AM -0700, Daniel Walker wrote:
> > On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote:
> > > Deprecating sysfs interfaces can be done within 6 months or so,
> > > especially if there's only one real consumer.
> >
> > I'll assume your right (can you give an example of this?), but why
> > should we even add it if we know it's already going to get replaced.
> > It's like it's pre-deprecated ..
>
> See feature-removal-schedule.txt. So far we have no indication that it's
> going to be replaced, because nobody has actually suggested a working
> way to do this better. If we had a concrete implementation proposal for
> that then we'd be in a pretty different position right now.

Ok, feature-removal-schedule.txt applies to everything tho. What your
saying is that if this interface only last a short time it might take 6
months, if it last for a long time it would take longer. There's no easy
way to know that Google is the only user after some amount of time
passes.

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: Matthew Garrett on
On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote:
> On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote:
> > See feature-removal-schedule.txt. So far we have no indication that it's
> > going to be replaced, because nobody has actually suggested a working
> > way to do this better. If we had a concrete implementation proposal for
> > that then we'd be in a pretty different position right now.
>
> Ok, feature-removal-schedule.txt applies to everything tho. What your
> saying is that if this interface only last a short time it might take 6
> months, if it last for a long time it would take longer. There's no easy
> way to know that Google is the only user after some amount of time
> passes.

If the interface is there for a long time, it's because we haven't come
up with anything better. And if we haven't come up with anything better,
the interface deserves to be there.

--
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: Tony Lindgren on
* Matthew Garrett <mjg(a)redhat.com> [100513 12:20]:
> On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote:
> > 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.
> >
> > I believe categorizing the apps should be instead done with some
> > timer flags or cgroups instead.
>
> I agree, but we have no mechanism for implementing that in a race-free
> way. We don't even have a realistical proposal for what that mechanism
> would look like. Should we refuse bread today for the promise of cake
> tomorrow?

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.

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/