From: Arve Hjønnevåg on
2010/8/7 Arve Hj�nnev�g <arve(a)android.com>:
> 2010/8/7 Rafael J. Wysocki <rjw(a)sisk.pl>:
>> On Saturday, August 07, 2010, Arve Hj�nnev�g wrote:
>>> 2010/8/6 Alan Stern <stern(a)rowland.harvard.edu>:
>>> > On Thu, 5 Aug 2010, Arve Hj�nnev�g wrote:
....
>>> >> total_time, total time the wake lock has been active. This one should
>>> >> be obvious.
>>> >
>>> > Also easily added.
>>> >
>>> Only with a handle passed to all the calls.
>>
>> Well, I'm kind of tired of this "my solution is the only acceptable one"
>> mindset. �IMHO, it's totally counter productive.
>>
>
> How do you propose to track how long a driver has blocked suspend when
> you have an unblock call that takes no arguments.
>

Also, I did not not see a response to my question about why you don't
want to pass a handle.

--
Arve Hj�nnev�g
--
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: Mark Brown on
On Fri, Aug 06, 2010 at 05:36:42PM -0700, Paul E. McKenney wrote:
> On Sat, Aug 07, 2010 at 01:14:32AM +0100, Mark Brown wrote:

> > services in themselves (like system monitoring). It's really just
> > semantics to treat them differently to something like a cellular modem -
> > at a high level they're both just independant processors ticking away
> > without the application processor.

> I agree that a smartphone's cellular modem can be argued to be very
> similar to wake-on-LAN. The smartphone applications that seem to me
> to be very different from wake-on-LAN are things like audio playback,
> where the system is providing service to the user during the time that
> it is suspended.

The cellular modem case includes not just hanging off the network but
also being on a call - the voice path for a phone call doesn't need the
CPU to do anything. It's probably best to view a phone as a bunch of
interconnected systems that happen to sit in the same box, and there's
various design decisions that can be taken about which systems own the
shared components.
--
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 Sat, 7 Aug 2010, Rafael J. Wysocki wrote:

> > Arguably not every PCI interrupt should be regarded as a wakeup event, so
> > I think we can simply say in the cases when that's necessary the driver should
> > be responsible for using pm_wakeup_event() or pm_stay_awake() / pm_relax() as
> > appropriate.
> >
> > My patch only added it to the bus-level code which covered the PME-based
> > wakeup events that _cannot_ be handled by device drivers.

In other words, your bus-level changes were a necessary but not
sufficient start. I can buy that.

> Also please note that it depends a good deal on the definition of a "wakeup
> event". Under the definition used when my patch was being developed, ie. that
> wakeup events are the events that would wake up the system from a sleep state,
> PCI interrupts cannot be wakeup events, unless the given device remains in the
> full power state although the system has been suspended (standard PCI devices
> are not allowed to generate signals except for PME from low-power states).

Um, what do you mean by "event"? Let's take a concrete example.
Suppose you have a system where you want USB plug or unplug events to
cause a wakeup. This is relevant to the discussion at hand if your USB
host controller is a PCI device.

By your reckoning, a plug or unplug event that occurs while the system
is asleep would be a wakeup event by definition. And yet you say that
the same plug or unplug event occurring while the controller was at
full power would not count as a wakeup event? And in particular, it
should not prevent the system from suspending before the event can be
fully processed? That doesn't make sense. The same event is the same
event, regardless of the context in which it occurs. If it is treated
as a wakeup event in context then it should be treated as a wakeup
event in other contexts too.

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: Paul E. McKenney on
On Sat, Aug 07, 2010 at 02:07:18PM +0100, Mark Brown wrote:
> On Fri, Aug 06, 2010 at 05:36:42PM -0700, Paul E. McKenney wrote:
> > On Sat, Aug 07, 2010 at 01:14:32AM +0100, Mark Brown wrote:
>
> > > services in themselves (like system monitoring). It's really just
> > > semantics to treat them differently to something like a cellular modem -
> > > at a high level they're both just independant processors ticking away
> > > without the application processor.
>
> > I agree that a smartphone's cellular modem can be argued to be very
> > similar to wake-on-LAN. The smartphone applications that seem to me
> > to be very different from wake-on-LAN are things like audio playback,
> > where the system is providing service to the user during the time that
> > it is suspended.
>
> The cellular modem case includes not just hanging off the network but
> also being on a call - the voice path for a phone call doesn't need the
> CPU to do anything. It's probably best to view a phone as a bunch of
> interconnected systems that happen to sit in the same box, and there's
> various design decisions that can be taken about which systems own the
> shared components.

OK, apologies, I thought you were talking about the wait-for-a-call case.
If there actually is a call ongoing, then the user perceives the system as
doing something, so this is similar to audio playback and quite different
from wake-on-LAN or system monitoring.

Thanx, Paul
--
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: Paul E. McKenney on
On Sat, Aug 07, 2010 at 03:00:48AM -0700, david(a)lang.hm wrote:
> On Sat, 7 Aug 2010, Rafael J. Wysocki wrote:
>
> >On Saturday, August 07, 2010, david(a)lang.hm wrote:
> >>On Sat, 7 Aug 2010, Mark Brown wrote:
> >>
> >>>On Fri, Aug 06, 2010 at 04:35:59PM -0700, david(a)lang.hm wrote:
> >>>>On Fri, 6 Aug 2010, Paul E. McKenney wrote:
> >...
> >>What we want to have happen in an ideal world is
> >>
> >>when the storage isn't needed (between reads) the storage should shutdown
> >>to as low a power state as possible.
> >>
> >>when the CPU isn't needed (between decoding bursts) the CPU and as much of
> >>the system as possible (potentially including some banks of RAM) should
> >>shutdown to as low a power state as possible.
> >
> >Unfortunately, the criteria for "not being needed" are not really
> >straightforward and one of the wakelocks' roles is to work around this issue.
>
> if you can ignore the activity caused by the other "unimportant"
> processes in the system, why is this much different then just the
> one process running, in which case standard power management sleeps
> work pretty well.

But isn't the whole point of wakelocks to permit developers to easily
and efficiently identify which processes are "unimportant" at a given
point in time, thereby allowing them to be ignored?

I understand your position -- you believe that PM-driving applications
should be written to remain idle any time that they aren't doing something
"important". This is a reasonable position to take, but it is also
reasonable to justify your position. Exactly -why- is this better?
Here is my evaluation:

o You might not need suspend blockers. This is not totally clear,
and won't be until you actually build a system based
on your design.

o You will be requiring that developers of PM-driving applications
deal with more code that must be very carefully coded and
validated. This requirement forces the expenditure of lots
of people time to save a very small amount of very inexpensive
memory (that occupied by the suspend-blocker code).

Keep in mind that there was a similar decision in the -rt kernel.
One choice was similar to your proposal: all code paths must call
schedule() sufficiently frequently. The other choice was to allow
almost all code paths to be preempted, which resembles suspend blockers
(preempt_disable() being analogous to acquiring a suspend blocker,
and preempt_enable() being analogous to releasing a suspend blocker).

Then as now, there was much debate. The choice then was preemption.
One big reason was that the choice of preemption reduced the amount of
real-time-aware code from the entire kernel to only that part of the
kernel that disabled preemption, which turned out to greatly simplify
the job of meeting aggressive scheduling-latency goals. This experience
does add some serious precedent against your position. So, what do you
believe is different in the energy-efficiency case?

> >>today there are two ways of this happening, via the idle approach (on
> >>everything except Android), or via suspend (on Android)
> >>
> >>Given that many platforms cannot go to into suspend while still playing
> >>audio, the idle approach is not going to be able to be eliminated (and in
> >>fact will be the most common approach to be used/deugged in terms of the
> >>types of platforms), it seems to me that there may be a significant amount
> >>of value in seeing if there is a way to change Android to use this
> >>approach as well instead of having two different systems competing to do
> >>the same job.
> >
> >There is a fundamental obstacle to that, though. Namely, the Android
> >developers say that the idle-based approach doesn't lead to sufficient energy
> >savings due to periodic timers and "polling applications".
>
> polling applications can be solved by deciding that they aren't
> going to be allowed to affect the power management decision (don't
> consider their CPU useage when deciding to go to sleep, don't
> consider their timers when deciding when to wake back up)

Agreed, and the focus is on how one decides which applications need
to be considered. After all, the activity of a highly optimized
audio-playback application looks exactly like that of a stupid polling
application -- they both periodically consume some CPU. But this is
something that you and the Android guys are actually agreeing about.
You are only arguing about exactly what mechanism should be used to
make this determination. The Android guys want suspend blockers, and
you want to extend cgroups.

So I believe that the next step for you is to implement your approach
so that it can be compared in terms of energy efficiency, code size,
intrusiveness, performance, and compatibility with existing code.

> >Technically that
> >boils down to the interrupt sources that remain active in the idle-based case
> >and that are shut down during suspend. If you found a way to deactivate all of
> >them from the idle context in a non-racy fashion, that would probably satisfy
> >the Android's needs too.
>
> well, we already have similar capibility for other peripherals (I
> keep pointing to drive spin down as an example), the key to avoiding
> the races seems to be in the drivers supporting this.

The difference is that the CPU stays active in the drive spin down
case -- if the drive turns out to be needed, the CPU can spin it up.
The added complication in the suspend case is that the CPU goes away,
so that you must more carefully plan for all of the power-up cases.

> the fact that Android is making it possible for suspend to
> selectivly avoid disabling them makes me think that a lot of the
> work needed to make this happen has probably been done. look at what
> would happen in a suspend if it decided to leave everything else on
> and just disable the one thing, that should e the same thing that
> happens if you are just disabling that one thing for idle sleep.

We already covered the differences between suspend and idle, now
didn't we? ;-)

Thanx, Paul
--
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/