Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 21:55:26 -0700
Brian Swetland wrote:
> On Thu, May 27, 2010 at 3:55 PM, Alan Cox wrote:
> >
> > This started because the Android people came to a meeting that was put
> > together of various folks to try and sort of the big blockage in getting
> > Android and Linux kernels back towards merging.
> >
> > I am interested right now in finding a general solution to the Android
> > case and the fact it looks very similar to the VM, hard RT, gamer and
> > other related problems although we seem to have diverged from that logic.
>
> I think that the suspend block model can be viewed as a constraints
> problem (similar to some of things things you've been sketching out in
> these threads), but I think we (Google/Android) view it as more of a
> state constraint (don't enter suspend) than a latency constraint.
>
> We think there's a need for these constraints both from the driver
> side and userspace side, and that these constraints are not tied to
> processes (multiple entities in one process may have different
> constraints at different times or multiple processes may be working
> together to accomplish some goal under a single constraint -- at least
> both cases exist in the Android system as it ships today).
>
> The exact naming of the API is not terribly important to us. The
> first thing we spent a bunch of time discussing last summer when Arve
> first looked into sending wakelocks upstream was changing the name
> because many objected to "wakelock" for various reasons.
>
> Being able to have userful statistics (which drivers/processes/etc
> held which wakelock for how long, how many times, etc) is important to
> us. While we want to do the best we can in the face of poorly written
> apps, we also want to educate users and developers about which apps
> are contributing to their poor battery life -- so users can decide to
> uninstall an app if its usefulness does not justify its impact on
> battery life and application developers can be more aware of what the
> cost of their app is to endusers.
>
> As an example, http://frotz.net/misc/battery-stats-unplugged.txt
> contains a dump from the "battery service" aggregating wakelock usage,
> cpu usage, and sensor device usage of processes (#: sections) on
> my phone the other day for a ~3 hour period. This data is presented
> visually to the enduser in a "what's using my battery" feature of the
> platform. "realtime" refers to wall clock time here and "uptime"
> refers to not-in-suspend execution time.
>
> Brian
Hi!
Thinking about the issue a little more, this isn't really about trusted
apps and not trusted apps. Or crapplications.
The point is, that as soon as an app takes a suspend-blocker it becomes
what is here referred to as a "trusted app". But just because it is then
visible as
consuming power in an official way.
Android suspends (as in echo mem > /sys/power/state)
whenever possible. It's as if there were a spring on the laptop lid,
and if the user doesnt hold his grip on it, the thing closes. How does
he hold his grip? The application registers a suspend-blocker for him.
So, why not use something like idle/QOS with this?
I can imagine to theoretically have a "latency requirement" where 0
means this application does not interact with the user. and != 0 means
this application interacts with the user.
("latency requirement" doesn't quite get it, but it works for now)
In android land, the default would be that every application has a
latency-requirement of 0. And then everything (userland) that takes a
suspend-blocker would be changed to take a "latency requirement != 0".
Now, if the system interacts with the user
( i.e. there is a global
latency requirement > 0, where "global latency requirement" is
computed by the pm framework maxing over all the userland processes
and the kernel side)
everything has to run. So we also need to schedule things which specify
a latency requirement == 0.
This last thing means, that it has to be independent of the scheduler, doesn't
it?
I don't see how renaming suspend_blocker to set_pidle would not do
something equivalent to this, but the bit's are probably a bit scattered
throughout the kernel.
(Which I don't think is introduced by that patch set, but by the fact that
suspend is currently not an idle state.)
I can understand if there needs to be a good solution in the kernel
from day 1.
So, what would compose to a good solution?
Here should probably the more experienced people jump in, but let me express
what i've gathered in this discussion (especially from Thomas and Alan Cox):
1. change suspend framework to be "just another idle state"
2. specify that "just another idle state" can only be entered if
"global latency requirement" == 0
3. probably add some cost-estimate-computation to the "just another
idle state"
(the trick here is, that this idle-state ignores all current measures of
"idle",
so the cost for this would only depend on the cost-estimate to enter it
RE: [PATCH v4 1/3] omap3 gpmc: functionality enhancement
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Vimal Singh
> Sent: Thursday, May 27, 2010 11:56 PM
> To: Ghorai, Sukumar
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH v4 1/3] omap3 gpmc: functionality enhancement
>
> On Thu, May 27, 2010 at 6:54 PM, Sukumar Ghorai wrote:
> [...]
> > -static unsigned gpmc_cs_map;
> > +static unsigned int gpmc_cs_map; /* flag for cs which are
> initialized */
>
> Tab should be after 'int', not before.
>
> [...]
> > @@ -456,13 +565,22 @@ EXPORT_SYMBOL(gpmc_prefetch_enable);
> > /**
> > * gpmc_prefetch_reset - disables and stops the prefetch engine
> > */
> > -void gpmc_prefetch_reset(void)
> > +int gpmc_prefetch_reset(int cs)
> > {
> > + u32 config1;
> > +
> > + /* check if the same module/cs is trying to reset */
> > + config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
> > + if (((config1 >> CS_NUM_SHIFT) & 0x7) != cs)
> > + return -EINVAL;
> > +
>
> You really do not need this.
> Prefetch has just one instance at a time and 'reset' will be call only
> when driver has got access to prefetch (for either read or write
> access), from the driver.
[Ghorai] Agree. And.. NAND may not be good example. But if tomorrow i/o
operation need to cancel for some other type of device and for big size of IO
on progress. So is not this API required that case?
>
> --
> Regards,
> Vimal Singh
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 10:15 PM, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 15:19 -0400, Alan Stern wrote: >> On Thu, 27 May 2010, Peter Zijlstra wrote: >> >> > I still don't see how blocking applications will cause missed wakeups in >> > anything but a buggy application at worst, and even those will >> > eventually get the event when they unblock. >> > >> > What seems to be the confusion? >> >> During forced suspend, applications are block because they are frozen. >> >> When an event occurs, the application is notified somehow. But it >> can't respond because it is frozen. Hence the event remains sitting in >> a kernel queue and the system goes ahead and suspends anyway. The >> application doesn't get thawed until the system wakes up at some >> indefinite time in the future. > > If the kernel is awake to put things in queues, we're clearly not > suspended and userspace is running ?! Suspend is not an atomic operation. User space is frozen before freezable kernel threads both of these happen before drivers are suspended. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 2010-05-27 at 15:19 -0400, Alan Stern wrote: > On Thu, 27 May 2010, Peter Zijlstra wrote: > > > I still don't see how blocking applications will cause missed wakeups in > > anything but a buggy application at worst, and even those will > > eventually get the event when they unblock. > > > > What seems to be the confusion? > > During forced suspend, applications are block because they are frozen. > > When an event occurs, the application is notified somehow. But it > can't respond because it is frozen. Hence the event remains sitting in > a kernel queue and the system goes ahead and suspends anyway. The > application doesn't get thawed until the system wakes up at some > indefinite time in the future. If the kernel is awake to put things in queues, we're clearly not suspended and userspace is running ?! -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 3:55 PM, Alan Cox wrote: > > This started because the Android people came to a meeting that was put > together of various folks to try and sort of the big blockage in getting > Android and Linux kernels back towards merging. > > I am interested right now in finding a general solution to the Android > case and the fact it looks very similar to the VM, hard RT, gamer and > other related problems although we seem to have diverged from that logic. I think that the suspend block model can be viewed as a constraints problem (similar to some of things things you've been sketching out in these threads), but I think we (Google/Android) view it as more of a state constraint (don't enter suspend) than a latency constraint. We think there's a need for these constraints both from the driver side and userspace side, and that these constraints are not tied to processes (multiple entities in one process may have different constraints at different times or multiple processes may be working together to accomplish some goal under a single constraint -- at least both cases exist in the Android system as it ships today). The exact naming of the API is not terribly important to us. The first thing we spent a bunch of time discussing last summer when Arve first looked into sending wakelocks upstream was changing the name because many objected to "wakelock" for various reasons. Being able to have userful statistics (which drivers/processes/etc held which wakelock for how long, how many times, etc) is important to us. While we want to do the best we can in the face of poorly written apps, we also want to educate users and developers about which apps are contributing to their poor battery life -- so users can decide to uninstall an app if its usefulness does not justify its impact on battery life and application developers can be more aware of what the cost of their app is to endusers. As an example, http://frotz.net/misc/battery-stats-unplugged.txt contains a dump from the "battery service" aggregating wakelock usage, cpu usage, and sensor device usage of processes (#: sections) on my phone the other day for a ~3 hour period. This data is presented visually to the enduser in a "what's using my battery" feature of the platform. "realtime" refers to wall clock time here and "uptime" refers to not-in-suspend execution time. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 11:55:46PM +0100, Alan Cox wrote: > > This started because the Android people came to a meeting that was put > together of various folks to try and sort of the big blockage in getting > Android and Linux kernels back towards merging. > > I am interested right now in finding a general solution to the Android > case and the fact it looks very similar to the VM, hard RT, gamer and > other related problems although we seem to have diverged from that logic. Keep in mind, though, that a solution which is acceptable for Android has to include making sure that crappy applications don't cause the battery to get drained. There seem to be some people who seem adamently against this requirement. From the Android folks' perspective, this is part of what is required to have an open app store, as opposed to one where each application has to be carefully screened and approved ala the Apple iPhone App Store. Maybe it would be acceptable if there were an easy way THAT A USER AND NOT A DEVELOPER COULD USE ON A SMART PHONE to find the bad application, but realistically, it's much better if the solution can work well even in the face of crappy application. Having interacted with application programmers, I can assure you there are a lot of crappy application programmers out there, and they vastly outnumber us kernel developers. (See as exhibit A all of the application programs who refuse to use fsync, even though it's going to wipe them out on all new modern file systems, including btrfs.) We need to agree on the requirements up front, because otherwise this is going to be a waste of everyone's time. And if we can't get agreement on requirements, I'd suggest appealing this whole thing to Linus. Either he'll agree to the requirements and/or the existing implementation, in which case we can move on with our lives, or he'll say no, in which case it will be blately obvious that it was Linux developer community who rejected the Android approach, despite a fairly large amount of effort trying to get something that satisfies *all* of the various LKML developers who have commented on this patch, and we can continue with Android having kernel which is different from mainline --- just as many other embedded companies have patches which are utterly required by their products, but which have been judged Too Ugly To Live In Mainline --- and we can also move on and get on with our lives. - Ted P.S. Keep in mind how this looks from an outsider's perspective; an embedded manufacturer spends a fairly large amount of time answering one set of review comments, and a few weeks later, more people pop up, and make a much deeper set of complaints, and request that the current implementation be completely thrown out and that someone new be designed from scratch --- and the new design isn't even going to meet all of the requirements that the embedded manufacturer thought were necessary. Is it any wonder a number of embedded developers have decided it's Just Too Hard to Work With the LKML? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 3:23 PM, Alan Cox wrote: > On Thu, 27 May 2010 23:09:49 +0100 > Matthew Garrett wrote: > >> On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote: >> >> > This is I believe robust (and has been implemented on some non x86 >> > boxes). It depends on not forcing running tasks into suspend. That is the >> > key. >> >> We've already established that ACPI systems require us to force running >> tasks into suspend. How do we avoid the race in that situation? > > Android phones do not have ACPI. Embedded platforms do not have ACPI. MID > x86 devices do not have ACPI. > Android does not only run on phones. It is possible that no android devices have ACPI, but I don't know that for a fact. What I do know is that people want to run Android on x86 hardware and supporting suspend could be very benficial. > I would imagine the existing laptops will handle power management limited > by the functionality they have available. Just like any other piece of > hardware. I think existing laptops (and desktops) can benefit from opportunistic suspend support. If opportunistic suspend is used for auto-sleep after inactivity instead of forced suspend, the user space suspend blocker api will allow an application to delay this auto sleep until for instance a download completes. This part could also be done with a user-space IPC call, but having a standard kernel interface for it may make it more common. A less common case, but more critical, is RTC alarms. I know my desktops can wakeup at a specific time by programming an RTC alarm, but without suspend blockers how do you ensure that the system does not suspend right after the alarm triggered? I have a system that wakes up at specific times requested by my DVR application, but I cannot use this system for anything else unless I manually turn off the DVR application's auto-sleep feature. With suspend blockers and something like the android alarm driver, I could use this system for more than one application that have scheduled tasks and it would be more usable for interactive applications. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Wed, 26 May 2010 14:24:30 +0200, Florian Mickler wrote: > Because he is using a robust kernel that provides suspend blockers and > is preventing the vampire from sucking power? > Suspend blockers are only a flawed and indirect way to keep the vampire from sucking. > Most users don't even grasp the simple concept of different "programs". > They just have a device and click here and there and are happy. > > Really, what are you getting at? Do you deny that there are programs, > that prevent a device from sleeping? (Just think of the bouncing > cows app) He's getting at the fact that there are much better ways to deal with this problem. The issue here is that we seem to be expected to swallow whatever Google throws at us, regardless of the quality of the solution. It seems like the best argument we have for merging is "we couldn't think of anything better and we need it yesterday." This might be a good enough reason for shipping, but it certainly doesn't satisfy the requirements for merging. > > And if you have two kernels, one with which your device is dead after 1 > hour and one with which your device is dead after 10 hours. Which would > you prefer? I mean really... this is ridiculous. It is absolutely not. If you want to keep power usage down, then implement real resource management in the scheduler. Suspend blockers are nothing but a clunky and ineffective means of resource allocation. As has been pointed out in this thread, there are much better ways of dealing with this problem. - Ben -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Fri, 28 May 2010, Rafael J. Wysocki wrote: > > And the forced-suspend design relies on the fact that processes remain > > frozen throughout. If we leave some processes unfrozen and one of them > > somehow becomes runnable, that means we have to abort the forced > > suspend before the process is allowed to run. > > We could avoid that if drivers could block tasks, but there are questions to > answer. First off, how a driver is supposed to know when to block the task > using it and when to do its power management transparently for the task? > Second, how to intercept and block all possible interfaces that user space > can use to talk to drivers (how to intercept a task using mmapped device, for > example)? We talked about this a few years ago and decided it was not feasible. It would require substantial changes to every device driver. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 5:05 PM, Rafael J. Wysocki wrote: > On Friday 28 May 2010, Alan Cox wrote: >> > The approach with user space power manager suggested by Dmitry and Alan >> > Stern >> > may work, but it still assumes some kind of suspend blockers to be present >> > in >> > the kernel. If we reject that too, I wonder what approach Google is >> > supposed >> > to use and still get the same battery life they get with suspend blockers. >> >> I'm getting less convinced it needs suspend blockers at all for this case, >> assuming that you are willing to have a policy that is based on >> >> - assuming apps play nicely >> - having the information to user space you need (who woke us, who blocked >> us, events) >> - dealing with offenders primarily from user space using that information >> >> I'm fairly happy about the following so far >> >> - we should have a common interface for seeing some pm events (like >> duh ?) but it does need careful thought so the watcher doesn't change >> the behaviour and break it. (Message "We are suspending", gosh someone >> is running to receive the message, resume being the obvious case) >> >> - Suspend is (for many platforms) just a cotinuation down the power >> chain. Demonstrated and implemented on ARM. Very much the direction of >> S0i1/S0i3 on x86 MID devices. Proved by the fact it has been done and >> made to work, and by reading the Moorestown PR. >> >> - Given a non forced (that is 'idle down') transition to a suspend level >> we can implement a 'suspend as idle' on many embedded platforms in a >> manner which is not racy at kernel level. Apparently implemented >> already on ARM >> >> - Given a non forced transition to such a suspend level and the reporting >> of certain events we can do a full user space managed graphical UI type >> environment policy in a race free fashion >> >> - With notification of who caused a resume and maybe a bit of other >> general stat gathering it is possible to identify and handle abuses of >> power resource. Proved by the fact we can do this with powertop but >> more elegance in the interfaces would be nice. >> >> I am not sure if a pm event is what is needed for this or a sum 'hardware >> triggered wake up' event. >> >> I accept that current ACPI based laptops probably couldn't make use of >> such a feature but I don't think this is important at the moment. > > No, it's not. > >> A resource constraint model might help further in the ACPI case. It's >> useful for other stuff but it might well be a distraction and >> implementation detail in terms of the basic question about what is needed >> for something like Android. >> >> At this point the input of the Android team and the Nokia people would >> be rather more useful to me. > > OK, I added Arve and Brian to the CC list. > Even if we used the proposed QoS replacement, are there suggestions on how to keep the cpu idle for longer than 2 seconds in Linux without using suspend? On a thread somewhere I had real world power numbers on a Motorola Droid idling (screen off) with and without suspend blockers. -- Mike > Thanks, > Rafael > ___ > linux-pm mailing list > linux...@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/linux-pm > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 4:50 PM, Alan Cox wrote:
>> That's correct, but to me the Arve's goal is simply to maximize battery life
>> and he found experimentally that the longest battery life is achieved if
>> system suspend is used whenever the system doesn't need to be active (from
>> its
>> user's perspective). This actually is different from "when the system is
>> idle", because the system isn't idle, for example, when updatedb is running.
>> However, from the user's perspective the updatedb process doesn't really need
>> to run at this particular time, it can very well do it's job in parallel with
>> the user typing or reading news. So, the system may very well be suspended
>> when updatedb is running.
>
> This is where the original questions around QoS came in
>
>> Since I think we've now rejected the feature, do we have a clear picture
>> about
>> what the Android people should do _instead_ and yet keep the battery life
>> they
>> want? Because I don't think telling "let them do what they want, who cares"
>> is right.
>
> Today "idle" means "no task running"
>
> If you are prepared to rephrase that as "no task that matters is running"
> what would need to answer ?
>
> - How do we define who matters: QoS ?
>
This is a much harder question to answer that what we need to use
opportunistic suspend. The question we ask is more like this: "Is all
important work complete?". In the simplest case these can be the same,
but on Android they are not. Some wakeup events require work to be
performed in many processes. A thread that needs to respond to a
wakeup event may currently be busy doing unimportant work. This could
possibly be solved by saying all important work must be above priority
N, but you would need full priority inheritance support and we are not
there today.
> - Can you describe "idle" in terms of QoS without then breaking the
> reliable wakeup for an event (and do you need to ?)
>
> Could this for example look like
>
> Set QoS of 'user apps' to QS_NONE
> Button pushed
> Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
>
What happens if the user presses the button right before you set QoS
of 'user apps' to QS_NONE?
To me it looks like this solution would result in this sequence which
may ignore the button press:
Button pushed
Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
Set QoS of 'user apps' to QS_NONE
> That would I think solve the reliable wakeup case although
> drivers raising a QoS parameter is a bit unusual in the kernel.
> That would at least however be specific to a few Android drivers
> and maybe a tiny amount of shared driver stuff so probably not
> unacceptable. (wake_up_pri(&queue, priority); isn't going to
> kill anyone is it - especially if it usually ignores the
> priority argument)
Why is "wake_up_pri(&queue, priority)" more acceptable than "suspend_block(..."?
>
> I am curious Thomas how that would tie in with PI in the RT
> world, it's effectively inheriting priority from the users finger.
>
> - Would a model where the UI side behaviour looked like
>
> Timeout
> Screen Off
> Set QoS of 'user apps' to QS_NONE
>
> Event
> [Some chain of activity]
> Screen On
> Set QoS of 'user apps' to QS_ABOVESUSPEND
>
> do the job combined with the ability to see who is stopping us dropping
> to suspend so user space can take action. This could be a data table
> from the Android cpu manager provided to Android specific policy in
> whoever owns the display.
>
>
> If so how do we fix the UI policy code doing
>
> Screen Off
> Button Press
> task to QS_ABOVESUSPEND
> task to QS_NONE
>
> without touching the app userspace code
>
>
> Perhaps
>
What happens if the button press happend before this line:
> count2 = tasks to QS_NONE | QS_NOTCHANGED
> Screen off
> Button Press
> task to QS_ABOVESUSPEND
> count = tasks that are QS_NOTCHANGED to QS_NONE
>
> if (count != count2) {
> Stuff happened ... rethink
> }
>
> That is still a bit weird and wonderful but all the logic is in the right
> places. The special magic remains in the Android policy code and in the
> kernel specifics for Android.
>
> Thoughts ?
I don't think it works. Also, it does not seem much less invasive than
suspend blockers.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Friday 28 May 2010, Alan Cox wrote:
> > That's correct, but to me the Arve's goal is simply to maximize battery life
> > and he found experimentally that the longest battery life is achieved if
> > system suspend is used whenever the system doesn't need to be active (from
> > its
> > user's perspective). This actually is different from "when the system is
> > idle", because the system isn't idle, for example, when updatedb is running.
> > However, from the user's perspective the updatedb process doesn't really
> > need
> > to run at this particular time, it can very well do it's job in parallel
> > with
> > the user typing or reading news. So, the system may very well be suspended
> > when updatedb is running.
>
> This is where the original questions around QoS came in
>
> > Since I think we've now rejected the feature, do we have a clear picture
> > about
> > what the Android people should do _instead_ and yet keep the battery life
> > they
> > want? Because I don't think telling "let them do what they want, who cares"
> > is right.
>
> Today "idle" means "no task running"
>
> If you are prepared to rephrase that as "no task that matters is running"
> what would need to answer ?
>
> - How do we define who matters: QoS ?
That's reasonable IMO.
> - Can you describe "idle" in terms of QoS without then breaking the
> reliable wakeup for an event (and do you need to ?)
>
> Could this for example look like
>
> Set QoS of 'user apps' to QS_NONE
> Button pushed
> Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
>
> That would I think solve the reliable wakeup case although
> drivers raising a QoS parameter is a bit unusual in the kernel.
> That would at least however be specific to a few Android drivers
> and maybe a tiny amount of shared driver stuff so probably not
> unacceptable. (wake_up_pri(&queue, priority); isn't going to
> kill anyone is it - especially if it usually ignores the
> priority argument)
>
> I am curious Thomas how that would tie in with PI in the RT
> world, it's effectively inheriting priority from the users finger.
>
> - Would a model where the UI side behaviour looked like
>
> Timeout
> Screen Off
> Set QoS of 'user apps' to QS_NONE
>
> Event
> [Some chain of activity]
> Screen On
> Set QoS of 'user apps' to QS_ABOVESUSPEND
>
> do the job combined with the ability to see who is stopping us dropping
> to suspend so user space can take action. This could be a data table
> from the Android cpu manager provided to Android specific policy in
> whoever owns the display.
>
>
> If so how do we fix the UI policy code doing
>
> Screen Off
> Button Press
> task to QS_ABOVESUSPEND
> task to QS_NONE
>
> without touching the app userspace code
>
>
> Perhaps
>
> count2 = tasks to QS_NONE | QS_NOTCHANGED
> Screen off
> Button Press
> task to QS_ABOVESUSPEND
> count = tasks that are QS_NOTCHANGED to QS_NONE
>
> if (count != count2) {
> Stuff happened ... rethink
> }
>
> That is still a bit weird and wonderful but all the logic is in the right
> places. The special magic remains in the Android policy code and in the
> kernel specifics for Android.
>
> Thoughts ?
Hmm. How do we prevent the "non-relevant" tasks from being scheduled
once we've decided to go for power saving?
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Fri, May 28, 2010 at 12:50:45AM +0100, Alan Cox wrote: > > That's correct, but to me the Arve's goal is simply to maximize battery life > > and he found experimentally that the longest battery life is achieved if > > system suspend is used whenever the system doesn't need to be active (from > > its > > user's perspective). This actually is different from "when the system is > > idle", because the system isn't idle, for example, when updatedb is running. > > However, from the user's perspective the updatedb process doesn't really > > need > > to run at this particular time, it can very well do it's job in parallel > > with > > the user typing or reading news. So, the system may very well be suspended > > when updatedb is running. > > This is where the original questions around QoS came in > > > Since I think we've now rejected the feature, do we have a clear picture > > about > > what the Android people should do _instead_ and yet keep the battery life > > they > > want? Because I don't think telling "let them do what they want, who cares" > > is right. > > Today "idle" means "no task running" > > If you are prepared to rephrase that as "no task that matters is running" > what would need to answer ? > > - How do we define who matters: QoS ? > > - Can you describe "idle" in terms of QoS without then breaking the > reliable wakeup for an event (and do you need to ?) > > Could this for example look like > > Set QoS of 'user apps' to QS_NONE > Button pushed > Button driver sets QoS of app it wakes to QS_ABOVESUSPEND > > That would I think solve the reliable wakeup case although > drivers raising a QoS parameter is a bit unusual in the kernel. > That would at least however be specific to a few Android drivers > and maybe a tiny amount of shared driver stuff so probably not > unacceptable. (wake_up_pri(&queue, priority); isn't going to > kill anyone is it - especially if it usually ignores the > priority argument) That should probably go into higher levels, not in individual drivers, so we should be able to limit spreading of wake_up_pri() or whatever throughout the tree. This particular case should be probably handled by evdev raising QoS of the user that is opened particular /dev/input/eventX. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Friday 28 May 2010, Alan Cox wrote: > > The approach with user space power manager suggested by Dmitry and Alan > > Stern > > may work, but it still assumes some kind of suspend blockers to be present > > in > > the kernel. If we reject that too, I wonder what approach Google is > > supposed > > to use and still get the same battery life they get with suspend blockers. > > I'm getting less convinced it needs suspend blockers at all for this case, > assuming that you are willing to have a policy that is based on > > - assuming apps play nicely > - having the information to user space you need (who woke us, who blocked > us, events) > - dealing with offenders primarily from user space using that information > > I'm fairly happy about the following so far > > - we should have a common interface for seeing some pm events (like > duh ?) but it does need careful thought so the watcher doesn't change > the behaviour and break it. (Message "We are suspending", gosh someone > is running to receive the message, resume being the obvious case) > > - Suspend is (for many platforms) just a cotinuation down the power > chain. Demonstrated and implemented on ARM. Very much the direction of > S0i1/S0i3 on x86 MID devices. Proved by the fact it has been done and > made to work, and by reading the Moorestown PR. > > - Given a non forced (that is 'idle down') transition to a suspend level > we can implement a 'suspend as idle' on many embedded platforms in a > manner which is not racy at kernel level. Apparently implemented > already on ARM > > - Given a non forced transition to such a suspend level and the reporting > of certain events we can do a full user space managed graphical UI type > environment policy in a race free fashion > > - With notification of who caused a resume and maybe a bit of other > general stat gathering it is possible to identify and handle abuses of > power resource. Proved by the fact we can do this with powertop but > more elegance in the interfaces would be nice. > > I am not sure if a pm event is what is needed for this or a sum 'hardware > triggered wake up' event. > > I accept that current ACPI based laptops probably couldn't make use of > such a feature but I don't think this is important at the moment. No, it's not. > A resource constraint model might help further in the ACPI case. It's > useful for other stuff but it might well be a distraction and > implementation detail in terms of the basic question about what is needed > for something like Android. > > At this point the input of the Android team and the Nokia people would > be rather more useful to me. OK, I added Arve and Brian to the CC list. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 4:43 PM, Rafael J. Wysocki wrote: > On Thursday 27 May 2010, Thomas Gleixner wrote: >> On Thu, 27 May 2010, Rafael J. Wysocki wrote: >> >> > On Thursday 27 May 2010, Thomas Gleixner wrote: >> > > On Thu, 27 May 2010, Alan Stern wrote: >> > > >> > > > On Thu, 27 May 2010, Felipe Balbi wrote: >> > > > >> > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: >> > > > > >If people don't mind, here is a greatly simplified summary of the >> > > > > >comments and objections I have seen so far on this thread: >> > > > > > >> > > > > > The in-kernel suspend blocker implementation is okay, even >> > > > > > beneficial. >> > > > > >> > > > > I disagree here. I believe expressing that as QoS is much better. Let >> > > > > the kernel decide which power state is better as long as I can say I >> > > > > need 100us IRQ latency or 100ms wakeup latency. >> > > > >> > > > 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 >> > > >> > > mem should be replaced by an idle suspend to ram mechanism >> > >> > Well, what about when I want the machine to suspend _regardless_ of whether >> > or not it's idle at the moment? That actually happens quite often to me. >> > :-) >> >> Fair enough. Let's agree on a non ambigous terminology then: >> >> forced: >> >> suspend which you enforce via user interaction, which >> also implies that you risk losing wakeups depending on >> the hardware properties > > OK > >> opportunistic: >> >> suspend driven from the idle context, which guarantees to >> not lose wakeups. Provided only when the hardware does >> provide the necessary capabilities. > > I can accept that definition, but this is not what "opportunistic" means in > the Is there a difference between this new definition of opportunistic and idle? I assume suspend here means low a low power sleep state since it is impossible to initiate and abort Linux suspend from idle since initiating suspend will cause the system to become not idle. > Arve's changelogs. What it means there is that he wants the system to suspend > even when it is not technically idle (like in the updatedb example I gave in a > previous message). Suspend blockers are supposed to be a mechanism by which > the kernel and user space together may determine when to suspend (and it's > somewhat orthogonal to idle). > -- Arve Hjønnevåg -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Friday 28 May 2010, Alan Cox wrote: > On Thu, 27 May 2010 23:55:13 +0200 > "Rafael J. Wysocki" wrote: > > > On Thursday 27 May 2010, Alan Cox wrote: > > > > > 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 ? > > > > I guess what Matthew wanted to say was that you couldn't use ACPI S3 as > > a very deep CPU idle state, because of the way wakeup sources are set up > > for it, while you could use it for aggressive power management with suspend > > blockers as proposed by Arve. > > Which is a nonsense. Because the entire Gnome desktop and KDE, and > OpenOffice and Firefox and friends would need fitting out with > suspend blockers. > > x86 hardware is moving to fix these problems (at least on handheld > devices initially). Look up the C6 power idle, and S0i1 and S0i3 > standby states. I reckon the laptop folks can probably get the hardware > fixed well before anyone can convert the entire PC desktop to include > blockers. To clarify, I'm not suggesting to spread suspend blockers all over the universe. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
> That's correct, but to me the Arve's goal is simply to maximize battery life
> and he found experimentally that the longest battery life is achieved if
> system suspend is used whenever the system doesn't need to be active (from its
> user's perspective). This actually is different from "when the system is
> idle", because the system isn't idle, for example, when updatedb is running.
> However, from the user's perspective the updatedb process doesn't really need
> to run at this particular time, it can very well do it's job in parallel with
> the user typing or reading news. So, the system may very well be suspended
> when updatedb is running.
This is where the original questions around QoS came in
> Since I think we've now rejected the feature, do we have a clear picture about
> what the Android people should do _instead_ and yet keep the battery life they
> want? Because I don't think telling "let them do what they want, who cares"
> is right.
Today "idle" means "no task running"
If you are prepared to rephrase that as "no task that matters is running"
what would need to answer ?
- How do we define who matters: QoS ?
- Can you describe "idle" in terms of QoS without then breaking the
reliable wakeup for an event (and do you need to ?)
Could this for example look like
Set QoS of 'user apps' to QS_NONE
Button pushed
Button driver sets QoS of app it wakes to QS_ABOVESUSPEND
That would I think solve the reliable wakeup case although
drivers raising a QoS parameter is a bit unusual in the kernel.
That would at least however be specific to a few Android drivers
and maybe a tiny amount of shared driver stuff so probably not
unacceptable. (wake_up_pri(&queue, priority); isn't going to
kill anyone is it - especially if it usually ignores the
priority argument)
I am curious Thomas how that would tie in with PI in the RT
world, it's effectively inheriting priority from the users finger.
- Would a model where the UI side behaviour looked like
Timeout
Screen Off
Set QoS of 'user apps' to QS_NONE
Event
[Some chain of activity]
Screen On
Set QoS of 'user apps' to QS_ABOVESUSPEND
do the job combined with the ability to see who is stopping us dropping
to suspend so user space can take action. This could be a data table
from the Android cpu manager provided to Android specific policy in
whoever owns the display.
If so how do we fix the UI policy code doing
Screen Off
Button Press
task to QS_ABOVESUSPEND
task to QS_NONE
without touching the app userspace code
Perhaps
count2 = tasks to QS_NONE | QS_NOTCHANGED
Screen off
Button Press
task to QS_ABOVESUSPEND
count = tasks that are QS_NOTCHANGED to QS_NONE
if (count != count2) {
Stuff happened ... rethink
}
That is still a bit weird and wonderful but all the logic is in the right
places. The special magic remains in the Android policy code and in the
kernel specifics for Android.
Thoughts ?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
Alan Cox writes: > - Given a non forced (that is 'idle down') transition to a suspend level > we can implement a 'suspend as idle' on many embedded platforms in a > manner which is not racy at kernel level. Apparently implemented > already on ARM Just to confirm, yes, it is already implemeted on ARM, and in mainline for the TI OMAP3 (ARM Cortex-A8) and in commercial products (Nokia N900, Moto Droid, Palm Pre, Archos, etc.) For the OMAP the deepest C-state is actually a fully powered-down ARM core. While the Droid uses 'suspend as idle' in addition to opportunistic suspend, the N900 *never* suspends in the traditional sense, it is entirely idle based. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thursday 27 May 2010, Thomas Gleixner wrote: > On Thu, 27 May 2010, Rafael J. Wysocki wrote: > > > On Thursday 27 May 2010, Thomas Gleixner wrote: > > > On Thu, 27 May 2010, Alan Stern wrote: > > > > > > > On Thu, 27 May 2010, Felipe Balbi wrote: > > > > > > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: > > > > > >If people don't mind, here is a greatly simplified summary of the > > > > > >comments and objections I have seen so far on this thread: > > > > > > > > > > > > The in-kernel suspend blocker implementation is okay, even > > > > > > beneficial. > > > > > > > > > > I disagree here. I believe expressing that as QoS is much better. Let > > > > > the kernel decide which power state is better as long as I can say I > > > > > need 100us IRQ latency or 100ms wakeup latency. > > > > > > > > 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 > > > > > > mem should be replaced by an idle suspend to ram mechanism > > > > Well, what about when I want the machine to suspend _regardless_ of whether > > or not it's idle at the moment? That actually happens quite often to me. > > :-) > > Fair enough. Let's agree on a non ambigous terminology then: > > forced: > >suspend which you enforce via user interaction, which >also implies that you risk losing wakeups depending on >the hardware properties OK > opportunistic: > >suspend driven from the idle context, which guarantees to >not lose wakeups. Provided only when the hardware does >provide the necessary capabilities. I can accept that definition, but this is not what "opportunistic" means in the Arve's changelogs. What it means there is that he wants the system to suspend even when it is not technically idle (like in the updatedb example I gave in a previous message). Suspend blockers are supposed to be a mechanism by which the kernel and user space together may determine when to suspend (and it's somewhat orthogonal to idle). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thursday 27 May 2010, Alan Stern wrote: > On Thu, 27 May 2010, Alan Cox wrote: > > > > 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 > > > > I don't think this is true. I think that is the root of the problem. > > Of course it's true. Just ask Arve -- he wants opportunistic suspend > and it _is_ a variant of forced suspend. Ergo he wants a new type of > forced suspend. Well, as I just wrote in a different message, what he _really_ wants is to get maximum possible battery life and he found experimentally that this is achieved by suspending the whole system as often as reasonably possible. Of course, the "reasonably possible" part needs clarification. > Maybe that's not what he _ought_ to want. Nevertheless, there are > valid reasons for wanting it. > > > I don't disagree with the user experience they are trying to create or > > the fact something is needed to make it possible (if it turns out we > > can't already do it). > > > > Forced suspend is sticking stuff in running state into suspend > > > > Power management models (such as Thomas ARM box) which we know work are > > 'when nothing is running' into suspend. > > > > So for me the real question on that side of this specific case is 'how > > do you make sure those tasks are idle when you need them to be' > > > > QoS ? > > Spanking them from user space ? > > Drivers enforcing policy elements by blocking tasks ? > > Currently we use the freezer. But it is a blunt tool -- it freezes > every user process. Also, it doesn't actually make processes > unrunnable; it just arranges things so that when they do run, they > immediately put themselves back to sleep. > > And the forced-suspend design relies on the fact that processes remain > frozen throughout. If we leave some processes unfrozen and one of them > somehow becomes runnable, that means we have to abort the forced > suspend before the process is allowed to run. We could avoid that if drivers could block tasks, but there are questions to answer. First off, how a driver is supposed to know when to block the task using it and when to do its power management transparently for the task? Second, how to intercept and block all possible interfaces that user space can use to talk to drivers (how to intercept a task using mmapped device, for example)? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thursday 27 May 2010, 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. > > > 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). > > So your position would seem to be "we have a race but can debate how big > is permissible" > > The usual model is > > "At no point should we be in a position when entering a suspend style > deep sleep where we neither abort the suspend, nor commit to a > suspend/resume sequence if the events we care about occur" > > and that is why the hardware model is > > 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. That's correct, but to me the Arve's goal is simply to maximize battery life and he found experimentally that the longest battery life is achieved if system suspend is used whenever the system doesn't need to be active (from its user's perspective). This actually is different from "when the system is idle", because the system isn't idle, for example, when updatedb is running. However, from the user's perspective the updatedb process doesn't really need to run at this particular time, it can very well do it's job in parallel with the user typing or reading news. So, the system may very well be suspended when updatedb is running. Now, "when the system doesn't need to be active" is not a very precise statement, so the Android people attempted to develop a mechanism allowing them to specify what that means more precisely. It works for them, it need not work for everyone, though. Of course, we can dismiss it as "crap", "broken design", whatever, but then we need to give them a clear advice what to do to achieve the same goal (maximum battery life) in a different way that would be more acceptable to us. Since I think we've now rejected the feature, do we have a clear picture about what the Android people should do _instead_ and yet keep the battery life they want? Because I don't think telling "let them do what they want, who cares" is right. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
> The approach with user space power manager suggested by Dmitry and Alan Stern > may work, but it still assumes some kind of suspend blockers to be present in > the kernel. If we reject that too, I wonder what approach Google is supposed > to use and still get the same battery life they get with suspend blockers. I'm getting less convinced it needs suspend blockers at all for this case, assuming that you are willing to have a policy that is based on - assuming apps play nicely - having the information to user space you need (who woke us, who blocked us, events) - dealing with offenders primarily from user space using that information I'm fairly happy about the following so far - we should have a common interface for seeing some pm events (like duh ?) but it does need careful thought so the watcher doesn't change the behaviour and break it. (Message "We are suspending", gosh someone is running to receive the message, resume being the obvious case) - Suspend is (for many platforms) just a cotinuation down the power chain. Demonstrated and implemented on ARM. Very much the direction of S0i1/S0i3 on x86 MID devices. Proved by the fact it has been done and made to work, and by reading the Moorestown PR. - Given a non forced (that is 'idle down') transition to a suspend level we can implement a 'suspend as idle' on many embedded platforms in a manner which is not racy at kernel level. Apparently implemented already on ARM - Given a non forced transition to such a suspend level and the reporting of certain events we can do a full user space managed graphical UI type environment policy in a race free fashion - With notification of who caused a resume and maybe a bit of other general stat gathering it is possible to identify and handle abuses of power resource. Proved by the fact we can do this with powertop but more elegance in the interfaces would be nice. I am not sure if a pm event is what is needed for this or a sum 'hardware triggered wake up' event. I accept that current ACPI based laptops probably couldn't make use of such a feature but I don't think this is important at the moment. A resource constraint model might help further in the ACPI case. It's useful for other stuff but it might well be a distraction and implementation detail in terms of the basic question about what is needed for something like Android. At this point the input of the Android team and the Nokia people would be rather more useful to me. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
Matthew: Remind me why the idle/QOS power management approach won't work here. If the difficulty is untrusted apps preventing the system from being idle, why not assign them to QoS(NONE) as Thomas suggested? If the difficulty is that some untrusted apps need to receive wakeup events, why not just decree that this is not allowed? It seems reasonable that if you can't trust a program then you shouldn't allow it to wake up the system. If the difficulty is that some trusted apps need to do CPU-burning things like drawing bouncing cows in the background, why not break these apps into two processes or threads? One can be trusted and receive all the wakeup events, and the other can be untrusted and draw all the cows it likes. We're only talking about trusted apps, most of which would be controlled by Google, so the conversion shouldn't be too hard. If the difficulty is that ACPI-based systems can't use idle/QOS PM effectively... well, so be it. We don't have to solve every problem in the world right away, and just now we're mainly concerned about helping the Android people. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 23:36:05 +0100 Matthew Garrett wrote: > On Thu, May 27, 2010 at 11:23:57PM +0100, Alan Cox wrote: > > On Thu, 27 May 2010 23:09:49 +0100 > > Matthew Garrett wrote: > > > > > On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote: > > > > > > > This is I believe robust (and has been implemented on some non x86 > > > > boxes). It depends on not forcing running tasks into suspend. That is > > > > the > > > > key. > > > > > > We've already established that ACPI systems require us to force running > > > tasks into suspend. How do we avoid the race in that situation? > > > > Android phones do not have ACPI. Embedded platforms do not have ACPI. MID > > x86 devices do not have ACPI. > > It doesn't matter. Right now there's a race condition in terms of > wakeup events on ACPI systems. What's your proposal for fixing that? I see it as a different problem - and one that seems to be minimally pressing to most users jduging by the amount of noise it hasn't caused in the past seven odd years. This started because the Android people came to a meeting that was put together of various folks to try and sort of the big blockage in getting Android and Linux kernels back towards merging. I am interested right now in finding a general solution to the Android case and the fact it looks very similar to the VM, hard RT, gamer and other related problems although we seem to have diverged from that logic. I dont think it particularly useful to go off on a mostly unrelated wild goose chase into ACPI land, especially one based on a premise of changing all the apps when the hardware will end up fixed faster. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thursday 27 May 2010, Matthew Garrett wrote: > On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote: > > > I'd prefer we avoided mixing them up. Everyone seems fairly happy with > > the current operator ordered suspend behaviour I believe ? > > No. The current mechanism can lose wakeup events. As long as the operator agrees to lose wakeup events occasionally, which is the case at least 99% of the time, there's nothing wrong with that IMO. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thursday 27 May 2010, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote: > > On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote: > > > > we still need to be able to enter suspend while the system isn't idle. > > > > > > _WHY_!? > > > > Because if I'm running a kernel build in a tmpfs and I hit the sleep > > key, I need to go to sleep. Blocking processes on driver access isn't > > sufficient. > > But that's a whole different issue. I agree that a forced suspend for > things like that make sense, just not for power managing a running > system. PC style hardware like that doesn't wake up from suspend for > funny things like a keypress either (good thing too). In fact one of my PC test boxes does that. :-) > Anyway all that already works (more or less), so I don't see the > problem. The whole idea behind the patchset is not to power manage a _running_ system. It is based on the observation that for a good deal of time one doesn't need the system to be running at all, which is quite pragmatic to me. Given that, the point is to figure out when the system doesn't need to run and effectively shut it down at that point (memory is refreshed in that state so that the system can go back to the working state relatively quickly). From there, the system can only be woken up by specific events (like pressing a power button). However, it would be wasteful to shut it down knowing that the condition used to make the decision to shut it down didn't hold any more. The current mainline relies on the user to make that decision (and write something to /sys/power/state), but in principle I don't see why it cannot be made by software (either the kernel or the user space, or both in combination). The question is how to "teach" the software to make that decision in a way that's acceptable to the user and the Arve's approach is an attempt to give an answer to it. Of course, you may not like it, but the truth is it works in practice reasonably well. That may not be an argument for merging it, but then we should at least tell the Android people what's fundamentally wrong with it and how to do it in a different way so that their own requirements are met. As long as we don't do that, we're rejecting it just because we don't like it. Yes, Alan Cox said why he thought the approach was fundamentally wrong from the technical standpoint and I appreciate that. I don't think, though, that we can give Google a serious advice how to achieve their goal (which is battery life comparable to what they get with suspend blockers) in any different way. The approach with user space power manager suggested by Dmitry and Alan Stern may work, but it still assumes some kind of suspend blockers to be present in the kernel. If we reject that too, I wonder what approach Google is supposed to use and still get the same battery life they get with suspend blockers. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 11:23:57PM +0100, Alan Cox wrote: > On Thu, 27 May 2010 23:09:49 +0100 > Matthew Garrett wrote: > > > On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote: > > > > > This is I believe robust (and has been implemented on some non x86 > > > boxes). It depends on not forcing running tasks into suspend. That is the > > > key. > > > > We've already established that ACPI systems require us to force running > > tasks into suspend. How do we avoid the race in that situation? > > Android phones do not have ACPI. Embedded platforms do not have ACPI. MID > x86 devices do not have ACPI. It doesn't matter. Right now there's a race condition in terms of wakeup events on ACPI systems. What's your proposal for fixing that? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 11:32:47PM +0100, Alan Cox wrote: > > The kernel performs no explicit notification to userspace. With legacy > > For a PC ACPI using type device /proc/acpi/events which wakes acpid which > wakes gnome-power-manager which wakes half the universe No, there's no explicit /proc/acpi/event notification on resume. > Do we need a better more generic version of the events files - maybe but > thats a rather different kettle of fish to suspend blockers. It's a requirement for any reasonable alternative approach. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
> The kernel performs no explicit notification to userspace. With legacy For a PC ACPI using type device /proc/acpi/events which wakes acpid which wakes gnome-power-manager which wakes half the universe Do we need a better more generic version of the events files - maybe but thats a rather different kettle of fish to suspend blockers. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 23:09:49 +0100 Matthew Garrett wrote: > On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote: > > > This is I believe robust (and has been implemented on some non x86 > > boxes). It depends on not forcing running tasks into suspend. That is the > > key. > > We've already established that ACPI systems require us to force running > tasks into suspend. How do we avoid the race in that situation? Android phones do not have ACPI. Embedded platforms do not have ACPI. MID x86 devices do not have ACPI. I would imagine the existing laptops will handle power management limited by the functionality they have available. Just like any other piece of hardware. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 23:55:13 +0200 "Rafael J. Wysocki" wrote: > On Thursday 27 May 2010, Alan Cox wrote: > > > > 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 ? > > I guess what Matthew wanted to say was that you couldn't use ACPI S3 as > a very deep CPU idle state, because of the way wakeup sources are set up > for it, while you could use it for aggressive power management with suspend > blockers as proposed by Arve. Which is a nonsense. Because the entire Gnome desktop and KDE, and OpenOffice and Firefox and friends would need fitting out with suspend blockers. x86 hardware is moving to fix these problems (at least on handheld devices initially). Look up the C6 power idle, and S0i1 and S0i3 standby states. I reckon the laptop folks can probably get the hardware fixed well before anyone can convert the entire PC desktop to include blockers. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote: > This is I believe robust (and has been implemented on some non x86 > boxes). It depends on not forcing running tasks into suspend. That is the > key. We've already established that ACPI systems require us to force running tasks into suspend. How do we avoid the race in that situation? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 10:56:37PM +0100, Alan Cox wrote: > On Thu, 27 May 2010 22:36:35 +0100 > Matthew Garrett wrote: > > No it doesn't. The kernel continues executing anything that was on the > > Would you like to come and watch my laptop resume ? With printk's if you > want. You appear at this point to be arguing that bumble bees can't > fly, while watching one. The kernel performs no explicit notification to userspace. With legacy graphics setups you'll get a VT switch, but X is entirely unaware that that's due to suspend and that's going away in any case. On a typical setup it's not even the kernel that does the VT switch to and from X - that's handled by a script that happens to be on the runqueue. So yeah, things kind of work as you suggest right now - but only by accident, not design. What you're describing requires a new interface to inform interested bits of userspace whenever you transition from your deep idle state into a less deep one. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 17:38:03 -0400 (EDT) Alan Stern wrote: > > 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. > > Okay, and the kernel never suspends. We _are_ talking about a kind of > forced suspend, right? No ? We are talking about just letting power management solve the whole problem for us. > > If the event > > gets in after pm decides to idle via suspend then it'll bounce through > > the kernel back to a kernel resume, > > No, it won't. That's the problem suspend blockers were meant to solve. > The event winds up sitting in a kernel queue, the PM core doesn't know > about it (that's what I meant above -- the PM core doesn't know as much > as you seem to think it does), and the suspend takes place regardless. No - because we are not forcing the suspend. The app must go idle. If you force the suspend of running processes then yes the entire thing goes castors up - which is why it's a bad idea to do so. > > or potentially through a full > > hardware/software suspend/resume bounce. > > It would be okay if that happened. But once the event gets into the > kernel and the hardware IRQ source has turned off, there's nothing to > cause the resume. Read the discussion about how the race is avoided at the hardware level. That race is I think not there and furthermore most drivers get it right already. There are several cases 1. IRQ during app layer (ie policy in user space) asking applications to go passive - The event occurs, we undo the app layer policy, easy (or app wakes process and we let it fall through) 2. IRQ after the app layer quiesces its clients - The task wakes, the app layer won't see it - the app layer allows suspend as an idle mode. Not a problem - the app is running the cpu policy manager will see this and not suspend until the app has been asleep for a bit. The app may well of course tell the UI layer 'hey I want you back on' and it take you back to the full on case. 3. IRQ after kernel suspend begins - The driver will refuse the suspend, we don't suspend, we unwind the resume so far, the app wakes, we propogate stuff back up to user space whose policy manager unwinds its position 4. IRQ after driver has done its final checks - Wake up lines are set - We suspend - We immediately get resumed - We follow the full resume path This is I believe robust (and has been implemented on some non x86 boxes). It depends on not forcing running tasks into suspend. That is the key. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thursday 27 May 2010, Thomas Gleixner wrote: > On Thu, 27 May 2010, Alan Stern wrote: > > > On Thu, 27 May 2010, Thomas Gleixner wrote: > > > > > Crap. Stop beating on those lost wakeup events. If we lose them then > > > the drivers are broken and do not handle the switch over correctly. Or > > > the suspend mechanism is broken as it does not evaluate the system > > > state correctly. Blockers are just papering over that w/o tackling the > > > real problem. > > > > That's the point -- suspend does not evaluate the system state > > correctly because it doesn't have the necessary information. Suspend > > blockers are a way of providing it that information. They don't paper > > over the problem; they solve it. > > Nonsense. The system state is well defined when a event is pending and > we just have to say good bye to the idea that forced suspend is a good > solution. It's not as it does not guarantee the event processing in > badly written apps and it does move the power consumption to a later > point in time for those apps which acquire/drop the blockers. Well, now you have stated that Android actually doesn't work. :-) Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thursday 27 May 2010, Alan Cox wrote: > > > 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 ? I guess what Matthew wanted to say was that you couldn't use ACPI S3 as a very deep CPU idle state, because of the way wakeup sources are set up for it, while you could use it for aggressive power management with suspend blockers as proposed by Arve. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Thomas Gleixner wrote: > > The two of you are talking at cross purposes. Thomas is referring to > > idle-based suspend and Matthew is talking about forced suspend. > > Yes, and forced suspend to disk is the same as force suspend to disk, > which has both nothing to do with sensible resource management. If I understand correctly, you are saying that all the untrusted applications should run with QoS(NONE). Then they could do whatever they wanted without causing any interference. And with idle-based power management (rather than forced suspend), there would be no issue with wakeup events getting unduly delayed. Unless one of those events was meant for an untrusted application. Is that the source of the difficulty? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 22:36:35 +0100 Matthew Garrett wrote: > On Thu, May 27, 2010 at 10:37:51PM +0100, Alan Cox wrote: > > On Thu, 27 May 2010 18:25:10 +0100 > > Matthew Garrett wrote: > > > How (and why) does the WoL (which may be *any* packet, not just a magic > > > one) turn the screen back on? > > > > Well on my laptop today it works like this > > > > A WoL packet arrives > > The CPU resumes > > Depp process, chipset and laptop BIOS magic happens > > The kernel gets called > > The kernel lets interested people know a resume occurred > > No it doesn't. The kernel continues executing anything that was on the Would you like to come and watch my laptop resume ? With printk's if you want. You appear at this point to be arguing that bumble bees can't fly, while watching one. > runqueue before the scheduler stopped. If you're using idle-based > suspend then there's nothing on the runqueue - the application that > should be scheduled because of the event is blocked on writing to the > screen. IFF its your bogus example IFF you don't have any task waiting for resume notifications (ie its not X) So take the PC desktop case and for simplicity sake lets assume the X application in question has either filled the socket (unlikely) or is mid query request so blocked on the socket. The important line then is 'The kernel lets interested people know a resume occurred' Interesting people includes X X therefore ends up on the runqueue X gets the display back in order X completes processing the outstanding X request and replies The application continues If I was blocked on say serial output then the resume is going to wake the serial driver, which will transmit the queue, which will wake the app. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 23:36:26 +0200
"Rafael J. Wysocki" wrote:
> On Thursday 27 May 2010, Peter Zijlstra wrote:
> > On Thu, 2010-05-27 at 13:32 -0400, Alan Stern wrote:
> >
> > > On some platforms (like those with ACPI), deeper power-savings are
> > > available by using forced suspend than by using idle.
> >
> > Sounds like something that's fixable, doesn't it?
>
> The fix would probably have to involve rewriting the ACPI spec.
We are on about the fourth version of ACPI already. ACPI evolves and
improves and extends. It's not an impossibility to sort that out if
everyone in the x86 OS world starts thinking 'How come their ARM platform
can do this'
We are also on at least the second suspend/resume model in Linux. The
first was 'isn't this APM stuff neat', the second is heavily oriented
around ACPI ideas. And we already have SoC people moving into the third
model and making it work on non-x6 ('suspend is not special').
I've not poked at the current desktop stuff enough to see if the
gnome-power-manager and friends handle pushing the suspend button with
dbus notifiers to apps. I guess it does.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Rafael J. Wysocki wrote: > On Thursday 27 May 2010, Thomas Gleixner wrote: > > On Thu, 27 May 2010, Alan Stern wrote: > > > > > On Thu, 27 May 2010, Felipe Balbi wrote: > > > > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: > > > > >If people don't mind, here is a greatly simplified summary of the > > > > >comments and objections I have seen so far on this thread: > > > > > > > > > > The in-kernel suspend blocker implementation is okay, even > > > > > beneficial. > > > > > > > > I disagree here. I believe expressing that as QoS is much better. Let > > > > the kernel decide which power state is better as long as I can say I > > > > need 100us IRQ latency or 100ms wakeup latency. > > > > > > 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 > > > > mem should be replaced by an idle suspend to ram mechanism > > Well, what about when I want the machine to suspend _regardless_ of whether > or not it's idle at the moment? That actually happens quite often to me. :-) Fair enough. Let's agree on a non ambigous terminology then: forced: suspend which you enforce via user interaction, which also implies that you risk losing wakeups depending on the hardware properties opportunistic: suspend driven from the idle context, which guarantees to not lose wakeups. Provided only when the hardware does provide the necessary capabilities. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 11:33:32PM +0200, Thomas Gleixner wrote: > On Thu, 27 May 2010, Alan Stern wrote: > > The two of you are talking at cross purposes. Thomas is referring to > > idle-based suspend and Matthew is talking about forced suspend. > > Yes, and forced suspend to disk is the same as force suspend to disk, > which has both nothing to do with sensible resource management. It doesn't matter. Current forced suspend to RAM is racy with respect to wakeup events and should be fixed. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Alan Cox wrote:
> > 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.
But not the kind of insight we need. See below.
> > 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.
Perhaps.
> 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.
Okay, and the kernel never suspends. We _are_ talking about a kind of
forced suspend, right?
> If the event
> gets in after pm decides to idle via suspend then it'll bounce through
> the kernel back to a kernel resume,
No, it won't. That's the problem suspend blockers were meant to solve.
The event winds up sitting in a kernel queue, the PM core doesn't know
about it (that's what I meant above -- the PM core doesn't know as much
as you seem to think it does), and the suspend takes place regardless.
> or potentially through a full
> hardware/software suspend/resume bounce.
It would be okay if that happened. But once the event gets into the
kernel and the hardware IRQ source has turned off, there's nothing to
cause the resume.
> 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.
Agreed. Badly behaved apps must not be allowed to block suspends. As
far as I'm concerned, we can ignore them.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 10:37:51PM +0100, Alan Cox wrote: > On Thu, 27 May 2010 18:25:10 +0100 > Matthew Garrett wrote: > > How (and why) does the WoL (which may be *any* packet, not just a magic > > one) turn the screen back on? > > Well on my laptop today it works like this > > A WoL packet arrives > The CPU resumes > Depp process, chipset and laptop BIOS magic happens > The kernel gets called > The kernel lets interested people know a resume occurred No it doesn't. The kernel continues executing anything that was on the runqueue before the scheduler stopped. If you're using idle-based suspend then there's nothing on the runqueue - the application that should be scheduled because of the event is blocked on writing to the screen. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thursday 27 May 2010, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 13:32 -0400, Alan Stern wrote: > > > On some platforms (like those with ACPI), deeper power-savings are > > available by using forced suspend than by using idle. > > Sounds like something that's fixable, doesn't it? The fix would probably have to involve rewriting the ACPI spec. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Alan Stern wrote: > On Thu, 27 May 2010, Matthew Garrett wrote: > > > On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote: > > > On Thu, 27 May 2010, Matthew Garrett wrote: > > > > 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 where is the problem ? > > > > The problem is that, right now, if a wakeup event is received between > > the point where userspace decides to start a suspend and userspace > > actually starts a suspend, that event may not abort the suspend. > > The two of you are talking at cross purposes. Thomas is referring to > idle-based suspend and Matthew is talking about forced suspend. Yes, and forced suspend to disk is the same as force suspend to disk, which has both nothing to do with sensible resource management. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 18:25:10 +0100 Matthew Garrett wrote: > On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote: > > > Suppose X (or whatever windowing system) will block all clients that try > > to draw when you switch off your screen. > > > > How would we not wake them when we do turn the screen back on and start > > servicing the pending requests again? > > How (and why) does the WoL (which may be *any* packet, not just a magic > one) turn the screen back on? Well on my laptop today it works like this A WoL packet arrives The CPU resumes Depp process, chipset and laptop BIOS magic happens The kernel gets called The kernel lets interested people know a resume occurred The X server sees this X reconfigures the display X redraws the display (either by sending everyone expose events or by keeping the bits, not sure how it works this week as it has changed over time) My desktop re-appears Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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 | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 13:29:18 -0400 (EDT) Alan Stern 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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Matthew Garrett wrote: > On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote: > > On Thu, 27 May 2010, Matthew Garrett wrote: > > > 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 where is the problem ? > > The problem is that, right now, if a wakeup event is received between > the point where userspace decides to start a suspend and userspace > actually starts a suspend, that event may not abort the suspend. The two of you are talking at cross purposes. Thomas is referring to idle-based suspend and Matthew is talking about forced suspend. Or at least, that's how it appears to me. No wonder you can't agree on anything. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
> Well, what about when I want the machine to suspend _regardless_ of whether > or not it's idle at the moment? That actually happens quite often to me. :-) I don't think it helps to combine them for this discussion ? > I don't see much difference between that and ACPI S3 other than the memory > contents are preserved in S3. It also is complete power off state - except > for > memory refresh and wakeup sources (which also may be active in S4). Agreed although I am pushed to think of many real world cases where it might matter. VM's maybe? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
> 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
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 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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thursday 27 May 2010, Alan Cox wrote: > > > Heck, for all I care, simply SIGKILL the thing and report it once the > > > user starts looking at his screen again. > > > > Provide incentive for Joe Clicker to improve his app, instead of cope > > with the shit he created. > > That isn't helpful. But if you feel like that I suggest you run with your > memory management protection disabled, it's really on there to deal with > crap code and its giving the wrong incentives. Come to think of it > you might want to remove your seatbelts and any safety catches or airbags > - it only encourages carelessness. > > The reality is you need a sane, generic, race free way to express your > requirements (eg for hard RT) and ditto for constraining the expression > (for 'crapplications') > > Arguing that you don't need to do this isn't useful. Android has > demonstrated a need to do this. RT has a need to do some of this. > Virtualisation wants elements of this etc. > > The question is how you do it right. I violently agree, thanks Alan! Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thursday 27 May 2010, Thomas Gleixner wrote: > On Thu, 27 May 2010, Alan Stern wrote: > > > On Thu, 27 May 2010, Felipe Balbi wrote: > > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: > > > >If people don't mind, here is a greatly simplified summary of the > > > >comments and objections I have seen so far on this thread: > > > > > > > > The in-kernel suspend blocker implementation is okay, even > > > > beneficial. > > > > > > I disagree here. I believe expressing that as QoS is much better. Let > > > the kernel decide which power state is better as long as I can say I > > > need 100us IRQ latency or 100ms wakeup latency. > > > > 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 > > mem should be replaced by an idle suspend to ram mechanism Well, what about when I want the machine to suspend _regardless_ of whether or not it's idle at the moment? That actually happens quite often to me. :-) > > attention to latencies or other requirements. > > s2disk is a totally different beast as it shuts down the box into the > complete power off state. I don't see much difference between that and ACPI S3 other than the memory contents are preserved in S3. It also is complete power off state - except for memory refresh and wakeup sources (which also may be active in S4). Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST
Since these hwmods do not have IDLEST, set the HWMOD_NO_IDLEST flag,
otherwise _enable() will fail due to failing _wait_target_ready().
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |9 ++---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |9 ++---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index e5530c5..a8b57a6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -65,7 +65,8 @@ static struct omap_hwmod omap2420_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l3_masters),
.slaves = omap2420_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l3_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
};
static struct omap_hwmod omap2420_l4_wkup_hwmod;
@@ -95,7 +96,8 @@ static struct omap_hwmod omap2420_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l4_core_masters),
.slaves = omap2420_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l4_core_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
};
/* Slave interfaces on the L4_WKUP interconnect */
@@ -115,7 +117,8 @@ static struct omap_hwmod omap2420_l4_wkup_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2420_l4_wkup_masters),
.slaves = omap2420_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap2420_l4_wkup_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
};
/* Master interfaces on the MPU device */
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 0852d95..8b1f74b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -65,7 +65,8 @@ static struct omap_hwmod omap2430_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l3_masters),
.slaves = omap2430_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l3_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
};
static struct omap_hwmod omap2430_l4_wkup_hwmod;
@@ -97,7 +98,8 @@ static struct omap_hwmod omap2430_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l4_core_masters),
.slaves = omap2430_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l4_core_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
};
/* Slave interfaces on the L4_WKUP interconnect */
@@ -117,7 +119,8 @@ static struct omap_hwmod omap2430_l4_wkup_hwmod = {
.masters_cnt= ARRAY_SIZE(omap2430_l4_wkup_masters),
.slaves = omap2430_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_l4_wkup_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
};
/* Master interfaces on the MPU device */
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 39b0c0e..e288b20 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -76,7 +76,8 @@ static struct omap_hwmod omap3xxx_l3_hwmod = {
.masters_cnt= ARRAY_SIZE(omap3xxx_l3_masters),
.slaves = omap3xxx_l3_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l3_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
};
static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
@@ -106,7 +107,8 @@ static struct omap_hwmod omap3xxx_l4_core_hwmod = {
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_core_masters),
.slaves = omap3xxx_l4_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l4_core_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
};
/* Slave interfaces on the L4_PER interconnect */
@@ -126,7 +128,8 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
.masters_cnt= ARRAY_SIZE(omap3xxx_l4_per_masters),
.slaves = omap3xxx_l4_per_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l4_pe
[PATCH 4/5] OMAP24xx: CM: fix mask used for checking IDLEST status
On OMAP24xx, the polarity for the IDLEST bits is opposite of OMAP3. The mask used to check this was using the bit position instead of the bit mask. This patch fixes the problem by using the bit mask instead of the bit field. Signed-off-by: Kevin Hilman --- arch/arm/mach-omap2/cm.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/cm.c b/arch/arm/mach-omap2/cm.c index 2d83565..721c3b6 100644 --- a/arch/arm/mach-omap2/cm.c +++ b/arch/arm/mach-omap2/cm.c @@ -50,15 +50,15 @@ int omap2_cm_wait_module_ready(s16 prcm_mod, u8 idlest_id, u8 idlest_shift) cm_idlest_reg = cm_idlest_offs[idlest_id - 1]; + mask = 1 << idlest_shift; + if (cpu_is_omap24xx()) - ena = idlest_shift; + ena = mask; else if (cpu_is_omap34xx()) ena = 0; else BUG(); - mask = 1 << idlest_shift; - /* XXX should be OMAP2 CM */ omap_test_timeout(((cm_read_mod_reg(prcm_mod, cm_idlest_reg) & mask) == ena), MAX_MODULE_READY_TIME, i); -- 1.7.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] OMAP: hwmod: add option for no locking in idle/enable paths
Some hwmods may be idled/enabled directly from within the core
idle/suspend path. Since interrupts are already disabled here,
the mutex-based locking in hwmod can sleep and will cause
potential deadlocks.
To fix, add a hwmod flag HWMOD_NO_IDLE_LOCKING which indicates to the
hwmod core that no locking should be done during the idle/enable
paths for this hwmod.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c | 16
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 77fef90..1ee2fb2 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1304,9 +1304,13 @@ int omap_hwmod_enable(struct omap_hwmod *oh)
if (!oh)
return -EINVAL;
- mutex_lock(&omap_hwmod_mutex);
+ if (!(oh->flags & HWMOD_NO_IDLE_LOCKING))
+ mutex_lock(&omap_hwmod_mutex);
+
r = _enable(oh);
- mutex_unlock(&omap_hwmod_mutex);
+
+ if (!(oh->flags & HWMOD_NO_IDLE_LOCKING))
+ mutex_unlock(&omap_hwmod_mutex);
return r;
}
@@ -1323,9 +1327,13 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
if (!oh)
return -EINVAL;
- mutex_lock(&omap_hwmod_mutex);
+ if (!(oh->flags & HWMOD_NO_IDLE_LOCKING))
+ mutex_lock(&omap_hwmod_mutex);
+
_idle(oh);
- mutex_unlock(&omap_hwmod_mutex);
+
+ if (!(oh->flags & HWMOD_NO_IDLE_LOCKING))
+ mutex_unlock(&omap_hwmod_mutex);
return 0;
}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 0eccc09..cc3f9a7 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -360,6 +360,7 @@ struct omap_hwmod_omap4_prcm {
#define HWMOD_NO_OCP_AUTOIDLE (1 << 4)
#define HWMOD_SET_DEFAULT_CLOCKACT (1 << 5)
#define HWMOD_NO_IDLEST(1 << 6)
+#define HWMOD_NO_IDLE_LOCKING (1 << 7)
/*
* omap_hwmod._int_flags definitions
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] OMAP: hwmod: allow idle after HWMOD_INIT_NO_IDLE
If an omap_hwmod is setup using HWMOD_INIT_NO_IDLE flag, there is
currently way to idle it since omap_hwmod_idle() requires the hwmod to
be in the enabled state.
This patch adds a check to omap_hwmod_idle() so if the hwmod was has
the INIT_NO_IDLE flag, calling omap_hwmod_idle() will still succeed.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 2fff39f..a127c9b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -939,7 +939,13 @@ static int _enable(struct omap_hwmod *oh)
*/
static int _idle(struct omap_hwmod *oh)
{
- if (oh->_state != _HWMOD_STATE_ENABLED) {
+ /*
+* To idle, hwmod must be enabled, EXCEPT if hwmod was
+* initialized using the INIT_NO_IDLE flag. In this case it
+* will not yet be enabled so we have to allow it to be idled.
+*/
+ if ((oh->_state != _HWMOD_STATE_ENABLED) &&
+ !(oh->flags & HWMOD_INIT_NO_IDLE)) {
WARN(1, "omap_hwmod: %s: idle state can only be entered from "
"enabled state\n", oh->name);
return -EINVAL;
@@ -954,6 +960,9 @@ static int _idle(struct omap_hwmod *oh)
oh->_state = _HWMOD_STATE_IDLE;
+ /* Clear init flag which should only affect first call to idle */
+ oh->flags &= ~HWMOD_INIT_NO_IDLE;
+
return 0;
}
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] OMAP: hwmod: if IDLEST fields are not set, use module defaults
In the _setup() hook, check for valid IDLEST fields. If not set, use
the module defaults since they are the same as the module defaults
for most hwmods.
Problem found because _wait_target_ready() will fail if IDLEST
fields are not valid.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index a127c9b..77fef90 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1036,6 +1036,12 @@ static int _setup(struct omap_hwmod *oh)
oh->_state = _HWMOD_STATE_INITIALIZED;
+ /* if IDLEST values are not set, use module defaults */
+ if (!oh->prcm.omap2.idlest_reg_id)
+ oh->prcm.omap2.idlest_reg_id = oh->prcm.omap2.prcm_reg_id;
+ if (!oh->prcm.omap2.idlest_idle_bit)
+ oh->prcm.omap2.idlest_idle_bit = oh->prcm.omap2.module_bit;
+
r = _enable(oh);
if (r) {
pr_warning("omap_hwmod: %s: cannot be enabled (%d)\n",
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] OMAP2/3: misc. hwmod fixes
This series is a set of misc. hwmod fixes needed for functioning runtime PM on OMAP2 and OMAP3. These were used to get an omap_device/hwmod-based runtime PM working an tested on OMAP3430 (omap3evm) and OMAP2 (n810) All of these have been previously posted in various forms, but here they are all collected into one place. This series is also available in the pm-wip/hwmods branch of my git tree. This series applies on top of Benoit's two fixup/cleanup series that Paul has accepted. Kevin Hilman (5): OMAP: hwmod: allow idle after HWMOD_INIT_NO_IDLE OMAP: hwmod: if IDLEST fields are not set, use module defaults OMAP: hwmod: add option for no locking in idle/enable paths OMAP24xx: CM: fix mask used for checking IDLEST status OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST arch/arm/mach-omap2/cm.c |6 ++-- arch/arm/mach-omap2/omap_hwmod.c | 33 ++ arch/arm/mach-omap2/omap_hwmod_2420_data.c |9 -- arch/arm/mach-omap2/omap_hwmod_2430_data.c |9 -- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12 ++--- arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + 6 files changed, 52 insertions(+), 18 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] OMAP: omap_device: add flag to disable automatic bus-level suspend/resume
As part of the runtime PM support, bus-level code can automatically
handle the enable/idle for each omap_device. There are, however, some
special cases where we don't want the bus-level layer to handle this,
and instead handle it manually.
Specific use cases are for omap_devices that are controlled
inside the idle path (like UART.)
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/include/plat/omap_device.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 3694b62..2cdbcdd 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -68,12 +68,16 @@ struct omap_device {
struct omap_device_pm_latency *pm_lats;
u32 dev_wakeup_lat;
u32 _dev_wakeup_lat_limit;
+ u32 flags;
u8 pm_lats_cnt;
s8 pm_lat_level;
u8 hwmods_cnt;
u8 _state;
};
+/* flags for struct omap_device */
+#define OMAP_DEVICE_NO_BUS_SUSPEND BIT(0)
+
/* Device driver interface (call via platform_data fn ptrs) */
int omap_device_enable(struct platform_device *pdev);
@@ -142,6 +146,7 @@ struct omap_device_pm_latency {
u32 flags;
};
+/* flags for struct omap_device_pm_latency */
#define OMAP_DEVICE_LATENCY_AUTO_ADJUST BIT(1)
/* Get omap_device pointer from platform_device pointer */
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] OMAP: PM: use omap_device API for suspend/resume
Hook into the platform bus methods for suspend and resume and
use the omap_device API to automatically idle and enable the
device on suspend and resume.
This allows device drivers to get rid of direct management of their
clocks in their suspend/resume paths, and let omap_device do it for
them.
We currently use the _noirq (late suspend, early resume) versions of
the suspend/resume methods to ensure that the device is not disabled
too early for any drivers also using the _noirq methods.
NOTE: only works for devices with omap_hwmod support.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm_bus.c | 61 ++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
index 69acaa5..3787da8 100644
--- a/arch/arm/mach-omap2/pm_bus.c
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -70,3 +70,64 @@ int platform_pm_runtime_idle(struct device *dev)
};
#endif /* CONFIG_PM_RUNTIME */
+#ifdef CONFIG_SUSPEND
+int platform_pm_suspend_noirq(struct device *dev)
+{
+ struct device_driver *drv = dev->driver;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *odev = to_omap_device(pdev);
+ int ret = 0;
+
+ if (!drv)
+ return 0;
+
+ if (drv->pm) {
+ if (drv->pm->suspend_noirq)
+ ret = drv->pm->suspend_noirq(dev);
+ }
+
+ if (omap_device_is_valid(odev)) {
+ if (odev->flags & OMAP_DEVICE_NO_BUS_SUSPEND) {
+ dev_dbg(dev, "no automatic bus-level system resume.\n");
+ return 0;
+ }
+
+ dev_dbg(dev, "%s\n", __func__);
+ omap_device_idle(pdev);
+ } else {
+ dev_dbg(dev, "not an omap_device\n");
+ }
+
+ return ret;
+}
+
+int platform_pm_resume_noirq(struct device *dev)
+{
+ struct device_driver *drv = dev->driver;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *odev = to_omap_device(pdev);
+ int ret = 0;
+
+ if (omap_device_is_valid(odev)) {
+ if (odev->flags & OMAP_DEVICE_NO_BUS_SUSPEND) {
+ dev_dbg(dev, "no automatic bus-level system resume.\n");
+ return 0;
+ }
+
+ dev_dbg(dev, "%s\n", __func__);
+ omap_device_enable(pdev);
+ } else {
+ dev_dbg(dev, "not an omap_device\n");
+ }
+
+ if (!drv)
+ return 0;
+
+ if (drv->pm) {
+ if (drv->pm->resume_noirq)
+ ret = drv->pm->resume_noirq(dev);
+ }
+
+ return ret;
+}
+#endif /* CONFIG_SUSPEND */
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] OMAP: PM: initial runtime PM core support
Implement the new runtime PM framework as a thin layer on top of the
omap_device API. Since we don't have an OMAP-specific bus, override
the runtime PM hooks for the platform_bus for the OMAP specific
implementation.
While the runtime PM API has three main states (idle, suspend, resume)
This version treats idle and suspend the same way by implementing both
on top of omap_device_disable(), which follows closely with how driver
are currently using clock enable/disable calls. Longer-termm
pm_runtime_idle() could take other constraints into consideration to
make the decision, but the current
Device driver ->runtime_suspend() hooks are called just before the
device is disabled (via omap_device_idle()), and device driver
->runtime_resume() hooks are called just after device has been
enabled (via omap_device_enable().)
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/Makefile |7 +++-
arch/arm/mach-omap2/pm_bus.c | 72 ++
2 files changed, 78 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/pm_bus.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4b9fc57..58a0474 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -46,12 +46,17 @@ obj-$(CONFIG_ARCH_OMAP2)+= sdrc2xxx.o
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o \
+ pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
+ifeq ($(CONFIG_PM_VERBOSE),y)
+CFLAGS_pm_bus.o+= -DDEBUG
+endif
+
endif
# PRCM
diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
new file mode 100644
index 000..69acaa5
--- /dev/null
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -0,0 +1,72 @@
+/*
+ * Runtime PM support code for OMAP
+ *
+ * Author: Kevin Hilman, Deep Root Systems, LLC
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#ifdef CONFIG_PM_RUNTIME
+int platform_pm_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *odev = to_omap_device(pdev);
+ int r, ret = 0;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ if (dev->driver->pm && dev->driver->pm->runtime_suspend)
+ ret = dev->driver->pm->runtime_suspend(dev);
+ if (!ret && omap_device_is_valid(odev)) {
+ r = omap_device_idle(pdev);
+ WARN_ON(r);
+ }
+
+ return ret;
+};
+
+int platform_pm_runtime_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *odev = to_omap_device(pdev);
+ int r, ret = 0;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ if (omap_device_is_valid(odev)) {
+ r = omap_device_enable(pdev);
+ WARN_ON(r);
+ }
+
+ if (dev->driver->pm && dev->driver->pm->runtime_resume)
+ ret = dev->driver->pm->runtime_resume(dev);
+
+ return ret;
+};
+
+int platform_pm_runtime_idle(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *odev = to_omap_device(pdev);
+ int ret;
+
+ ret = pm_runtime_suspend(dev);
+ dev_dbg(dev, "%s [%d]\n", __func__, ret);
+
+ return 0;
+};
+#endif /* CONFIG_PM_RUNTIME */
+
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] platform_bus: allow custom extensions to system PM methods
When runtime PM for platform_bus was added, it allowed for platforms
to customize the runtime PM methods since they are defined as weak
symbols.
This patch allows platforms to also extend the system PM methods with
custom hooks so runtime PM and system PM extensions can be managed
together by custom platform-specific code.
Signed-off-by: Kevin Hilman
Cc: Magnus Damm
Cc: Rafael Wysocki
Cc: Dmitry Torokhov
Cc: Eric Miao
Signed-off-by: Greg Kroah-Hartman
---
drivers/base/platform.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4b4b565..0bc478a 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -735,7 +735,7 @@ static void platform_pm_complete(struct device *dev)
#ifdef CONFIG_SUSPEND
-static int platform_pm_suspend(struct device *dev)
+int __weak platform_pm_suspend(struct device *dev)
{
struct device_driver *drv = dev->driver;
int ret = 0;
@@ -753,7 +753,7 @@ static int platform_pm_suspend(struct device *dev)
return ret;
}
-static int platform_pm_suspend_noirq(struct device *dev)
+int __weak platform_pm_suspend_noirq(struct device *dev)
{
struct device_driver *drv = dev->driver;
int ret = 0;
@@ -769,7 +769,7 @@ static int platform_pm_suspend_noirq(struct device *dev)
return ret;
}
-static int platform_pm_resume(struct device *dev)
+int __weak platform_pm_resume(struct device *dev)
{
struct device_driver *drv = dev->driver;
int ret = 0;
@@ -787,7 +787,7 @@ static int platform_pm_resume(struct device *dev)
return ret;
}
-static int platform_pm_resume_noirq(struct device *dev)
+int __weak platform_pm_resume_noirq(struct device *dev)
{
struct device_driver *drv = dev->driver;
int ret = 0;
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] runtime PM support at the bus level
This series introduces runtime PM support at the platform bus level for OMAP. In a nutshell, when using the runtime PM API for any device with an assocated omap_device (and hwmod), the omap device API will be used to handle the hardware-level power management of that device, including managing clocks, etc. Today, most drivers handle this by manually enabling/disabling their clocks when needed. With this series (and an omap_device/hwmod for each device) direct clock managment can be removed from the driver in favor of using the runtime PM API. NOTE: the 1st patch is FYI only, it has already been merged into mainline for 2.6.35 via the driver core. This applies on v2.6.34 and has been tested along with Benoit's two hwmod fixes/cleanup series and the work-in-progress UART and MMC hwmod conversions and has been tested on OMAP3430 (omap3evm) and OMAP2 (n810). This series is also available in my git tree as the 'pm-wip/runtime' branch. Kevin Hilman (4): platform_bus: allow custom extensions to system PM methods OMAP: PM: initial runtime PM core support OMAP: PM: use omap_device API for suspend/resume OMAP: omap_device: add flag to disable automatic bus-level suspend/resume arch/arm/mach-omap2/Makefile |7 +- arch/arm/mach-omap2/pm_bus.c | 133 + arch/arm/plat-omap/include/plat/omap_device.h |5 + drivers/base/platform.c |8 +- 4 files changed, 148 insertions(+), 5 deletions(-) create mode 100644 arch/arm/mach-omap2/pm_bus.c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 09:53:47PM +0100, Alan Cox wrote: > > Not lost, but not delivered. So you need your policy agent to send > > it will be delivered next time the process wakes. It's not lost. > > > SIGCONT when you receive any wakeup event, which either means proxying > > all your network traffic through your policy agent or having some > > mechanism for alerting the policy agent whenever you leave the deep idle > > state. > > You didn't mention that requirement last time. I thought it was pretty obvious that wakeup events had to actually be delivered to the applications that are listening for them. > > > > also the race of an application being in the middle of handling a > > > > wakeup > > > > event when you send it the signal. > > > > > > sigmask() > > > > 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. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH pm-wip/uart 0/4] misc. fixes for IDLEST and OMAP24xx support
Kevin Hilman writes: > This series on top of my pm-wip/uart branch fixes up various issues > with UART hwmods for 24xx as well as IDLEST issues after Benoit's > fixes/cleanup series. > > Tested on OMAP3 (omap3evm) and OMAP2 (n810/2420). > > Note that for OMAP2, this recently posted patch is required as well: > > [PATCH] OMAP24xx: CM: fix mask used for checking IDLEST status > > These ares posted as FYI, and will be folded into the original hwmod > data for OMAP2+ UARTs. > > Kevin > > > Kevin Hilman (4): > OMAP3: hwmod: UART: add module offs > OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST > OMAP2420: hwmod: UART3 needs prcm_reg_id = 2 > 24xx: need .module_offs = CORE_MOD FYI. This series has been folded into the original UART hwmod conversion patch in an updated pm-wip/uart branch. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 10:03:14PM +0100, Alan Cox wrote: > On Thu, 27 May 2010 18:59:20 +0100 > Matthew Garrett wrote: > > Ok. So the existing badly-behaved application ignores your request and > > then gets blocked. And now it no longer responds to wakeup events. So > > you penalise well-behaved applications without providing any benefits to > > badly-behaved ones. > > I don't see how you put the first two sentences together and get the > final one. > > When you beat up badly behaved apps that doesn't penalise well behaved > ones. If you're going to block an app on drawing then you either need to reenable drawing on wakeup or you need to have an interface for alerting the app to the fact that drawing is about to block and it should get back to its event loop. The first is suboptimal, the second penalises well behaved apps. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pm-wip/uart][PATCH 0/6]: Serial HWMOD updation and cleanup.
Hi Govindraj, "Govindraj.R" writes: > Patch series is based on remotes/origin/pm-wip/govindraj > branch from Kevin's PM tree. > > Patches are tested with 3430SDP. > Have updated 2420/2430 hwmod data files > it would be great if some one can test the same. OK, I've updated pm-wip/uart to include most of this series as well as some of the other fixes I posted yesterday to get things working on OMAP2. > Govindraj.R (6): > Serial: Clean up set_uart_globals. > Serial: Add UART4 hwmod data. > Serial: Modify OMAP3 hwmod data file with uart data. > Serial: Add UART hwmod data for 2420. > Serial: Add UART hwmod data for 2430. > Serial: Update UART HWMOD layer. I've kept patch 1 as is, but changed the subject slightly. Patches 2, 4 and 5 I've folded into the patch that added hwmod data for OMAP3. Patch 6 I folded into the initial UART conversion patch and also changed the authorship for that patch to you, since you've done most of that work. Patch 3, I've dropped as that shouldn't be needed after you switch to platform_get_resource_byname(). Please update your omap-serial driver on top of the new pm-wip/uart branch and then we'll be basically ready for upstream. Kevin > arch/arm/mach-omap2/omap_hwmod_2420_data.c | 184 > > arch/arm/mach-omap2/omap_hwmod_2430_data.c | 184 > > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 66 +- > arch/arm/mach-omap2/prcm-common.h |2 + > arch/arm/mach-omap2/serial.c | 38 +++ > arch/arm/plat-omap/common.c| 17 --- > arch/arm/plat-omap/include/plat/common.h |1 - > arch/arm/plat-omap/include/plat/dma.h |2 + > arch/arm/plat-omap/include/plat/irqs.h |2 + > 9 files changed, 449 insertions(+), 47 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thursday 27 May 2010, Thomas Gleixner wrote: > On Thu, 27 May 2010, Alan Stern wrote: > > On Thu, 27 May 2010, Peter Zijlstra wrote: > > > > > On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote: > > > > On Thu, 27 May 2010 17:09:16 +0200 > > > > Peter Zijlstra wrote: > > > > > > > > > On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote: > > > > > > > > > > > > Opportunistic suspends are okay. > > > > > > > > > > > > The proposed userspace API is too Android-specific. > > > > > > > > > > I would argue opportunistic suspends are not ok, and therefore the > > > > > proposed API is utterly irrelevant. > > > > > > > > Assuming you are happy that opportunistically entering C6 and the like > > > > is > > > > ok via ACPI can you explain why you have a problem with opportunistic > > > > suspend and why it is different to a very deep sleep CPU state such as > > > > we > > > > have now (and which on many embedded platforms we deal with *is* > > > > sleeping > > > > external devices too) > > > > > > Agreed, but I understood the opportunistic suspend line from Alan Stern > > > to mean the echo opportunistic > /sys/power/foo thing. > > > > Yes, that's what I meant. Why do you think it is any worse than "echo > > mem >/sys/power/state"? The only difference is that it will block > > until all in-kernel suspend blockers are disabled. > > > > Or do you also think that "echo mem >/sys/power/state" is evil and > > should be removed from the kernel as soon as possible? > > > > And to answer Thomas's question: The whole reason for having in-kernel > > suspend blockers is so that userspace can tell the system to suspend > > without losing wakeup events. > > > > Suppose a key is pressed just as a user program writes "mem" to > > /sys/power/state. The keyboard driver handles the keystroke and queues > > an input event. Then the system suspends and doesn't wake up until > > some other event occurs -- even though the keypress was an important > > one and it should have prevented the system from suspending. > > > > With in-kernel suspend blockers and opportunistic suspend, this > > scenario is prevented. That is their raison-d'etre. > > I tend to disagree. You are still looking at suspend as some extra > esoteric mechanism. We should stop doing this and look at suspend (to > RAM) as an additional deep idle state, which is well defined in terms > of power savings and wakeup latency. Well, the ACPI spec doesn't agree with you. :-) > That's what I think opportunistic suspend is all about. Now if you look at > our current idle states in x86 the incoming keystroke is never lost. > > So when suspend does lose the wakeup event then we need to fix that, With ACPI, we can't, because we have to switch our wakeup sources from the "runtime" mode to the "system wakeup" mode in a racy fashion. > but why do we need suspend blockers for this ? Let's take your example: > > > The keyboard driver handles the keystroke and queues an input > > event. Then the system goes into suspend > > Why do we go into suspend at all? The decision to go to suspend may be made in parallel to the keystroke in such a way that we may not be able to detect it (that doesn't apply to the hardware Android currently runs on, though). > If there is an event queued then something is woken up and got running, > which is reason enough _not_ to enter suspend. If that's broken in the > current implementation then we need to fix it, That's not a matter of implementation (which I admit can be improved). > but not with a big hammer by adding another > interface. We have that information already and obviously we do not > use it, so lets figure out why before adding suspend blockers just > because they paper over the underlying problem. I'm not really sure what information you're referring to. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 18:59:20 +0100 Matthew Garrett wrote: > On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote: > > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote: > > > > > If that's what you're aiming for then you don't need to block > > > applications on hardware access because they should all already have > > > idled themselves. > > > > Correct, a well behaved app would have. I thought we all agreed that > > well behaved apps weren't the problem? > > Ok. So the existing badly-behaved application ignores your request and > then gets blocked. And now it no longer responds to wakeup events. So > you penalise well-behaved applications without providing any benefits to > badly-behaved ones. I don't see how you put the first two sentences together and get the final one. When you beat up badly behaved apps that doesn't penalise well behaved ones. Forcing "well behaved apps" to make hundreds of extra calls to a complex blocker interface that also requires tons of kernel code and requires the application know platform policy and be recompiled if it changes - now that is punishing well behaved apps. A well behaved app should just work using standard existing APIs because that is how all the standard current well behaved apps are written [1]. Alan -- [1] I'm dying to see the suspend blocker patch for evolution ;) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
> > The event was not lost. > > Not lost, but not delivered. So you need your policy agent to send it will be delivered next time the process wakes. It's not lost. > SIGCONT when you receive any wakeup event, which either means proxying > all your network traffic through your policy agent or having some > mechanism for alerting the policy agent whenever you leave the deep idle > state. You didn't mention that requirement last time. > > > also the race of an application being in the middle of handling a wakeup > > > event when you send it the signal. > > > > sigmask() > > 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. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote: > On Thu, 27 May 2010, Matthew Garrett wrote: > > 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 where is the problem ? The problem is that, right now, if a wakeup event is received between the point where userspace decides to start a suspend and userspace actually starts a suspend, that event may not abort the suspend. > > Consider the case where the read() is non-blocking. > > Which I consider in the same range as the application which does: > > while (1); Not at all. Depending on what it reads, it may follow some other path where it sleeps. But, as I keep saying, if you don't want to support that kind of code then all of this is massively easier. > > What sets that flag, and how does it interact with an application that > > never makes a blocking system call? > > QoS(NONE) would be default policy for untrusted apps in the same way > as you'd refuse the usage of supsend blockers for untrusted apps. > > while (1); is definitely not an application which should be granted > trusted rights, right ? No, but if that while (1) is draw_cows() then the user may want this to run while their session is active and stop running while their session is idle. So you only want it to be QoS(NONE) in the idle session case. How do you change that state? > > The numbers were earlier in the thread. > > Numbers, yes. But I really give a sh*t about numbers w/o a detailed > explanation of the scenario which created those numbers. And if the > numbers boil down to: we handle the untrusted app which does "while > (1);" then they are absolutely useless. The tested case was a stock Android install with opportunistic suspend enabled and one that just used runtime idle. The lowest power state entered was the same on both. > > 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. > > Why in the world should they lose wakeup events ? If an app goes idle, > it goes idle because it is waiting for an event. There is no other > sane reason except for those apps which are untrusted and force > idled. And for those you agreed already the suspend blockers don't > solve anything as they are either not implemented or the app is not > trusted to use them. > > So we are back to round one of the whole discussion: > >Is it worth to create an utter mess in the kernel just to handle a >subset of crappy coded applications ? > > And the answer stays the same: No, not at all. You need suspend blockers to avoid losing wakeups in the explicit suspend case even if you don't want to implement opportunistic suspend. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: omap3 pm: dependency between opp layer and cpufreq
From: Menon, Nishanth Sent: Thursday, May 27, 2010 9:57 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: omap3 pm: dependency between opp layer and cpufreq [snip]--[snip] [sp] Responding via webmail.. so the formatting and quotes are non-standard :( > # OPP support in (OMAP3+ only at the moment) > # XXX The OPP TWL/TPS code should only be included when a TWL/TPS > # PMIC is selected. > ifdef CONFIG_CPU_FREQ > obj-$(CONFIG_ARCH_OMAP3) += opp.o opp_twl_tps.o ok this needs to be split: a) opp_twl_tps should depend on TWL_CORE and not CPUFREQ - there is no need actually b) opp.o should remain dependent on CPU_FREQ. [sp] That was in my next mail. > endif > > But changing CONFIG_CPU_FREQ to CONFIG_TWL4030_POWER leads to these errors: see (b) > [snip--[snip] > > Questions/ comments: > > 1) The linkage between OPP and Voltage are not driven by the PMIC. > They are defined by/for the silicon itself. look carefully at twl -> it is the abstraction where needed for pmic translation of a voltage value - this you agree is PMIC dependent I suppose. > > 2) The implementation for setting the voltage should depend upon the PMIC. ACK- the concept should be independent of PMIC - each PMIC, like 5030/tps Vs custom PMICs have thier own unique mechanisms of setting voltages - the renewed SR series from Thara addresses this concern.(not in pm branch yet - but potentially soon) > > 3) Was there any specific need to tie the functions "opp_get_voltage" and > others to cpufreq only? yes, because without cpufreq there is no transitions in the system :) [sp] I does - via bootarg - mpurate! When kernel boots, volatge must be set properly. We cannot rely on u-boot to be settiing everything correctly. e.g. 720MHz on OMAP3530 would fail at nominal 1.2V set by u-boot. > > I am working on a patch that should remove some of these dependencies. > But, trying to open up a discussion as well... do post them. thanks > > Best regards, > Sanjeev > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Matthew Garrett wrote:
> 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 where is the problem ?
> > > > 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();100 cycles
> > }
> >
> > vs.
> >
> > while (1) {
> > read();
> > ---> suspend
> > <--- resume
> > process_event();
> > do_crap();100 cycles
> > }
> >
> > You spend the damned 1000 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.
Which I consider in the same range as the application which does:
while (1);
> > 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?
QoS(NONE) would be default policy for untrusted apps in the same way
as you'd refuse the usage of supsend blockers for untrusted apps.
while (1); is definitely not an application which should be granted
trusted rights, right ?
block_suspend(); while(1);
is the same as:
QoS(minimal latency); while(1);
So if you really go to trust an "while (1);" application you better
make sure that this app has the appropriate QoS(NONE) or QoS(10s)
call in it before letting it lose.
> > 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.
Numbers, yes. But I really give a sh*t about numbers w/o a detailed
explanation of the scenario which created those numbers. And if the
numbers boil down to: we handle the untrusted app which does "while
(1);" then they are absolutely useless.
> > 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.
Why in the world should they lose wakeup events ? If an app goes idle,
it goes idle because it is waiting for an event. There is no other
sane reason except for those apps which are untrusted and force
idled. And for those you agreed already the suspend blockers don't
solve anything as they are either not implemented or the app is not
trusted to use them.
So we are back to round one of the whole discussion:
Is it worth to create an utter mess in the kernel just to handle a
subset of crappy coded applications ?
And the answer stays the same: No, not at all.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 08:53:33PM +0100, Alan Cox wrote: > On Thu, 27 May 2010 20:29:26 +0100 > Matthew Garrett wrote: > > But wakeup events won't be delivered to STOPped processes, and there's > > Try the following > > catkill -STOP catpid > > echo "wombats are cool" > pipe > kill -CONT catpid > > it will echo "wombats are cool" > > The event was not lost. Not lost, but not delivered. So you need your policy agent to send SIGCONT when you receive any wakeup event, which either means proxying all your network traffic through your policy agent or having some mechanism for alerting the policy agent whenever you leave the deep idle state. > > also the race of an application being in the middle of handling a wakeup > > event when you send it the signal. > > sigmask() Doesn't help - I may be hit by the signal between the poll() unblocking and me having the opportunity to call sigmask(). -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 08:50:09PM +0100, Alan Cox wrote: > So I guess if you are driving this rom user space (which I take it you > are given you talk about housekeeping) > > foreach app we need to suspend > kick app to suspend (signal) > (policy) kick harder if needed (SIGSTOP/bitch/shall I > kill it dialogue) This would need to be atomic, but in any case: 1) Policy decision is made 2) Wakeup event is received by task 3) Task gets stopped between receiving the event and handing it off to policy agent At which point you suspend when you should have remained awake. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
> We were talking about PCs. Suspend-as-c-state is already implemented for > OMAP. "You" were talking about PCs. Some of us are interested in the making Linux do the right thing not adding platform specific hacks all over the userspace of all the apps. > > 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. So do lots of other things > > Runnable tasks and QoS guarantees are the indicators whether you can > > go to opportunistic suspend or not. Everything else is just window > > dressing. > > As I keep saying, this is all much less interesting if you don't care > about handling suboptimal applications. If you do care about them then I don't believe the Android one does either. It maybe handles a subset in a specific case. > the Android approach works. Nobody has demonstrated a scheduler-based > one that does. I would point you at the web, cgi scripts and the huge Linux server farms fielding billions of hits per second on crap cgi scripts. That doesn't mean the Android one is the right approach. Nobody has explained to me how you don't get synchronization effects in Android or indeed answered several of the questions pointing out holes in the Android model. The fact we are at rev 8 says something too - that the Android 'proof' isn't old or tested either ! Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 19:23:03 +0100 Matthew Garrett wrote: > On Thu, May 27, 2010 at 08:18:49PM +0200, Thomas Gleixner wrote: > > On Thu, 27 May 2010, Matthew Garrett wrote: > > > Actually, the reverse - there's no terribly good way to make PCs work > > > with scheduler-based suspend, but there's no reason why they wouldn't > > > work with the current opportunistic suspend implementation. > > > > How does that solve the problems you mentioned above ? Wakeup > > guarantees, latencies ... > > Latency doesn't matter because we don't care when the next timer is due > to expire. In your specific current implementation. It matters a hell of a lot in most cases. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 20:29:26 +0100 Matthew Garrett wrote: > On Thu, May 27, 2010 at 08:25:38PM +0100, Alan Cox wrote: > > > The scheduler can happily do this, the power management will also > > recognize STOPPED processes as no impediment to suspend. > > But wakeup events won't be delivered to STOPped processes, and there's Try the following cat pipe kill -CONT catpid it will echo "wombats are cool" The event was not lost. > also the race of an application being in the middle of handling a wakeup > event when you send it the signal. sigmask() -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
> Sigh. No. Forced suspend is a fact of life
'Fact of life' isn't a useful reasoning basis. It tells me nothing about
how you got to that pronouncement.
> 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.
See above. You can't always abort the suspend you may have to go full
circle. Not only that but the exactly algorithm above can be applied
user to kernel as well as kernel to hardware.
Given your average app author I think I'd rather just run their suspend
then their resume handling back to back anyway because it's a single
tested code path, while half way through cases in apps will *never* get
tested or work properly.
So I guess if you are driving this rom user space (which I take it you
are given you talk about housekeeping)
foreach app we need to suspend
kick app to suspend (signal)
(policy) kick harder if needed (SIGSTOP/bitch/shall I
kill it dialogue)
rendezvous (apps now all sleeping or dead)
X
if (we still want to suspend) {
prod kernel
kernel suspends
kernel resumes
}
resume all the apps
The important msising bit from that is 'set wake flags'.
Now what actually happens here beyond point X. Any event that gets kernel
processed moves the task into RUNNING. Any event that occurs after that
point causes the hardware to go suspend/resume. If not the driver is
buggy.
Now replace "kernel suspends" with "let the kernel know it can drop into
suspend level idle". The power management code will handle the races
beyond point X for you.
So for that you simply need a constraint to remain above suspend level
idle that you drop where it says "prod kernel" and pick up on "resume"
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Alan Cox wrote: > > 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 > > I don't think this is true. I think that is the root of the problem. Of course it's true. Just ask Arve -- he wants opportunistic suspend and it _is_ a variant of forced suspend. Ergo he wants a new type of forced suspend. Maybe that's not what he _ought_ to want. Nevertheless, there are valid reasons for wanting it. > I don't disagree with the user experience they are trying to create or > the fact something is needed to make it possible (if it turns out we > can't already do it). > > Forced suspend is sticking stuff in running state into suspend > > Power management models (such as Thomas ARM box) which we know work are > 'when nothing is running' into suspend. > > So for me the real question on that side of this specific case is 'how > do you make sure those tasks are idle when you need them to be' > > QoS ? > Spanking them from user space ? > Drivers enforcing policy elements by blocking tasks ? Currently we use the freezer. But it is a blunt tool -- it freezes every user process. Also, it doesn't actually make processes unrunnable; it just arranges things so that when they do run, they immediately put themselves back to sleep. And the forced-suspend design relies on the fact that processes remain frozen throughout. If we leave some processes unfrozen and one of them somehow becomes runnable, that means we have to abort the forced suspend before the process is allowed to run. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:56:58PM +0100, Matthew Garrett wrote: > Even if it's using poll, it could block purely on the display if X turns > the screen off between poll() waking and the write being made. That's what fcntl(fd, F_SETFL, O_NONBLOCK) is for. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 08:25:38PM +0100, Alan Cox wrote: > The scheduler can happily do this, the power management will also > recognize STOPPED processes as no impediment to suspend. But wakeup events won't be delivered to STOPped processes, and there's also the race of an application being in the middle of handling a wakeup event when you send it the signal. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Peter Zijlstra wrote: > On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote: > > On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote: > > > > we still need to be able to enter suspend while the system isn't idle. > > > > > > _WHY_!? > > > > Because if I'm running a kernel build in a tmpfs and I hit the sleep > > key, I need to go to sleep. Blocking processes on driver access isn't > > sufficient. > > But that's a whole different issue. I agree that a forced suspend for > things like that make sense, just not for power managing a running > system. Why not? Or rather, why shouldn't it? > PC style hardware like that doesn't wake up from suspend for > funny things like a keypress either (good thing too). Yes it does. If I close the lid of my laptop, wait a few seconds for it to suspend, then open the lid (which does not wake it up), and hit a key -- it wakes up. > Anyway all that already works (more or less), so I don't see the > problem. The "less" part is the problem. It would be nice to have a forced suspend mode that is more dicriminating: Instead of activating immediately it would wait until all pending events were handled. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
> 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 I don't think this is true. I think that is the root of the problem. I don't disagree with the user experience they are trying to create or the fact something is needed to make it possible (if it turns out we can't already do it). Forced suspend is sticking stuff in running state into suspend Power management models (such as Thomas ARM box) which we know work are 'when nothing is running' into suspend. So for me the real question on that side of this specific case is 'how do you make sure those tasks are idle when you need them to be' QoS ? Spanking them from user space ? Drivers enforcing policy elements by blocking tasks ? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Peter Zijlstra wrote: > I still don't see how blocking applications will cause missed wakeups in > anything but a buggy application at worst, and even those will > eventually get the event when they unblock. > > What seems to be the confusion? During forced suspend, applications are block because they are frozen. When an event occurs, the application is notified somehow. But it can't respond because it is frozen. Hence the event remains sitting in a kernel queue and the system goes ahead and suspends anyway. The application doesn't get thawed until the system wakes up at some indefinite time in the future. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
> 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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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 | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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(); 100 cycles
> }
>
> vs.
>
> while (1) {
> read();
> ---> suspend
> <--- resume
> process_event();
> do_crap(); 100 cycles
> }
>
> You spend the damned 1000 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 | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
> > 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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010 19:17:58 +0100 Matthew Garrett wrote: > On Thu, May 27, 2010 at 08:06:38PM +0200, Peter Zijlstra wrote: > > On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote: > > > On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote: > > > > On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote: > > > > > > > > > If that's what you're aiming for then you don't need to block > > > > > applications on hardware access because they should all already have > > > > > idled themselves. > > > > > > > > Correct, a well behaved app would have. I thought we all agreed that > > > > well behaved apps weren't the problem? > > > > > > Ok. So the existing badly-behaved application ignores your request and > > > then gets blocked. And now it no longer responds to wakeup events. > > > > It will, when it gets unblocked from whatever thing it got stuck on. > > It's blocked on the screen being turned off. It's supposed to be reading > a network packet. How does it ever get to reading the network packet? Thats a stupid argument. If you write broken code then it doesn't work. You know if I do ls < unopenedfifo it blocks too. There is a difference between dealing with apps that overconsume resources and arbitarily broken code (which your suspend blocker case doesn't fix either but makes worse). Can we stick to sane stuff ? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, 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. > > > 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). > > So your position would seem to be "we have a race but can debate how big > is permissible" > > The usual model is > > "At no point should we be in a position when entering a suspend style > deep sleep where we neither abort the suspend, nor commit to a > suspend/resume sequence if the events we care about occur" > > and that is why the hardware model is > > 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. And if a platform can not guarantee the wakeup or the lossless transition of states then you can not solve this by throwing blockers or whatever into the code. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, May 27, 2010 at 07:48:40PM +0100, Alan Cox wrote: > > The application is a network monitoring app that renders server state > > via animated bouncing cows. The desired behaviour is that the > > application will cease to be scheduled if the session becomes idle > > (where idle is defined as the system having received no user input for > > 30 seconds) but that push notifications from the server still be > > received in order to allow the application to present the user with > > critical alerts. > > This is a bit confusing - does the screen come back on for such events, > what constraints is the server operating under ? How does your code look > - it's hard to imagine the examples you've given as being workable given > they would block on network packet wait when a critical event occurs. > Are you using poll or threads or what ? It's code that's broadly identical to what I posted. The screen will come on if the event is critical, won't otherwise. > > Under Android: > > > > User puts down phone. 30 seconds later the screen turns off and releases > > the last user-level suspend block. The phone enters suspend and the > > application is suspended. A network packet is received, causing the > > network driver to take a suspend block. The application finishes the > > frame it was drawing, takes its own suspend block and reads the network > > packet. In doing so the network driver releases its suspend block, but > > since userspace is holding one the phone stays awake. The application > > then handles the event as necessary, releases its suspend block and the > > phone goes to sleep again. > > > > I don't see how this behaviour can be emulated in your model. > > User puts down phone. 30 seconds later the X server decides to turn the > screen off and closes the device. This probalby releases the constraint > held via the display driver not to suspend. Any further draw requests will > block. > > System looks at the other tasks and sees they are idle and can sink to a > low power state. Cows is either blocked on a packet receive or could even > be blocked on writing to the display (or both if its a realistic example > and using poll) Even if it's using poll, it could block purely on the display if X turns the screen off between poll() waking and the write being made. > The kernel looks at the constraints it has > - must not sink to a state below which network receive of packets > fails > - must not sink below a state where whatever is needed for the > critical alert code etc to do its stuff > - must not sink to a state which takes more than [constraint] > seconds to get back out of > > It picks 'opportunistic suspend' > It goes to sleep > > A packet arrives > It wakes the hardware > We are busy, we do not wish to suspend > It processes the packet > It wakes the user app > It starts processing the packet If it's blocked on the write then it only starts processing the packet again if the screen wakes up. You need to power up every piece of hardware that an application's blocked on, just in case they need to complete that read or write in order to get back to the event loop where they have the opportunity to read the network packet. So, yes, I think this can work in that case. But it doesn't work in others - you won't idle applications that aren't accessing hardware drivers. As an aside, I think this is a good idea in any case since a fringe benefit is the removal of the requirement to use the process freezer in suspend to RAM... > Stop transitioning Run->Forced Suspend. If you've got stuff stuck running > then deal with it by constraining it to go idle or by blowing it out of > the water. PM will then do the rest. 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. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
> 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. > 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). So your position would seem to be "we have a race but can debate how big is permissible" The usual model is "At no point should we be in a position when entering a suspend style deep sleep where we neither abort the suspend, nor commit to a suspend/resume sequence if the events we care about occur" and that is why the hardware model is 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. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Matthew Garrett wrote: > On Thu, May 27, 2010 at 08:18:11PM +0200, Peter Zijlstra wrote: > > On Thu, 2010-05-27 at 19:14 +0100, Matthew Garrett wrote: > > > 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. > > > > Please re-read Thomas' description of how a driver should do the state > > transition. > > > > So either we get the packet before suspend, and we cancel the suspend, > > or we get it after and we wake up. What's the problem, and how does that > > need suspend blockers? > > In order to cancel the suspend we need to keep track of whether > userspace has consumed the event and reacted appropriately. Since we > can't do this with the process scheduler, we end up with something that > looks like suspend blockers. And the scheduler based approach does exactly this and provides exactly the same non guarantees to applications which are set to QoS(NONE) as it does to applications which do not (or are not allowed to) use the user space suspend blockers. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Thu, 27 May 2010, Matthew Garrett wrote:
> On Thu, May 27, 2010 at 07:59:02PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 May 2010, Matthew Garrett wrote:
> > > ACPI provides no guarantees about what level of hardware functionality
> > > remains during S3. You don't have any useful ability to determine which
> > > events will generate wakeups. And from a purely practical point of view,
> > > since the latency is in the range of seconds, you'll never have a low
> > > enough wakeup rate to hit it.
> >
> > Right, it does not as of today. So we cannot use that on x86
> > hardware. Fine. That does not prevent us to implement it for
> > architectures which can do it. And if x86 comes to the point where it
> > can handle it as well we're going to use it. Where is the problem ? If
> > x86 cannot guarantee the wakeup sources it's not going to be used for
> > such devices. The kernel just does not provide the service for it, so
> > what ?
>
> 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 ?
> > 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();100 cycles
}
vs.
while (1) {
read();
---> suspend
<--- resume
process_event();
do_crap();100 cycles
}
You spend the damned 1000 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.
An you are also stubbornly refusing to answer my analysis about the
effect on apps which do not use the blocker or are not allowed to.
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 ?
2) What's the difference on setting that app to QoS(NONE) and let the
kernel happily ignore it.
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.
> > Runnable tasks and QoS guarantees are the indicators whether you can
> > go to opportunistic suspend or not. Everything else is just window
> > dressing.
>
> As I keep saying, this is all much less interesting if you don't care
> about handling suboptimal applications. If you do care about them then
> the Android approach works. Nobody has demonstrated a scheduler-based
> one that does.
That does not make the android approach any better. They should have
talked to us upfront and not after the fact. Just because they decided
to do that in their google basement w/o talking to people who care is
not proving that it's a good solution and even less a reason to merge
it as is.
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.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
Matthew Garrett writes: > On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote: > >> I'd prefer we avoided mixing them up. Everyone seems fairly happy with >> the current operator ordered suspend behaviour I believe ? > > No. The current mechanism can lose wakeup events. And the proposed solution (suspend blockers) does nothing to solve the loss of wakeup events during forced suspend. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
