Attempted summary of suspend-blockers LKML thread
in [Kernel]
|
Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....
From: Alan Stern on 1 Aug 2010 18:20 On Sun, 1 Aug 2010, Paul E. McKenney wrote: > > I should have made a stronger point: "power-aware" is _not_ a good > > term for these applications. "power-enabled" would be better but > > still not ideal. Maybe "power-permitted"? The definition is that > > they are _permitted_ to do something (acquire suspend blockers), not > > that they actually _do_ something. > > How about "PM-driving applications", as Rafael suggested? Perhaps. But it's a little misleading, since what these applications are permitted to do is to _prevent_ the system from going to low power. So in a real sense they don't drive PM -- they block it. (Indeed, that's what inspired the name "suspend blocker".) Of course, the same objection applies to "power-permitted". > > I was agreeing with the requirement but disagreeing with the reason > > given for it. Even when buffers are large enough that the danger of > > overrunning them is infinitesimal, delays in input event delivery are > > still undesirable. > > > > Besides, the Android kernel doesn't vary its behavior based on whether > > the recipient is power-permitted or power-naive; it _always_ delivers > > input events in a timely fashion. > > True, the difference between the two classes of applications is in > whether or not the application is permitted to process the event. > > I added "and to minimize response latencies" to the requirement. > Does that capture it? Yes. > > > But leaving that aside, I thought that Arve and Brian explicitly > > > stated this as a requirement on power-aware applications -- one of the > > > responsibilities that came with the power to block suspend. > > > > No. There are _no_ requirements on power-permitted (or power-aware if > > you prefer) applications, other than that the user decides to give it > > the appropriate permission. > > > > Internally, of course, Android may enforce this rule on their own > > software. But it has no force in regard to external applications. > > So should this be moved to a new "ANDROID POLICY" section or some such? Or DESIRED BEHAVIOR, or some such. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Brownell on 1 Aug 2010 18:40 > > > I should have made a stronger point: > "power-aware" is _not_ a good > > > term for these applications.� Strongly disagree. The whole point is that they ARE VERY MUCH AWARE and interact with a power policy to achieve goals. Like refusing to power down active subsystems, or actively powering down inactive ones. Q.E.D. ... "aware". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arjan van de Ven on 1 Aug 2010 18:50 On Sun, 1 Aug 2010 12:27:08 -0700 "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> wrote: > On Sun, Aug 01, 2010 at 08:49:43AM +0200, Mikael Abrahamsson wrote: > > On Sun, 1 Aug 2010, Mikael Abrahamsson wrote: > > > > >it's just that mobile (low power) wasn't the intended target of > > >the application when it was written, and this commonly shows. > > Good points in both this and your earlier post!!! > > > I have another aspect I just thought about. I work for a telephony > > company. We provide Internet connectivity throught various means, > > DSL, Ethernet to the Home, mobile etc. > > > > For ETTH and DSL, network usage is pretty straight forward, you send > > packets, they get delivered pretty quickly with low marginal cost > > per packet. For mobile, this is not quite so simple. Mobile networks > > are designed for terminal/UE (user equipment) to use low power, so > > they go down in low power state after a while. Let's take the case > > of 3G/HSPA: > > > > After a short while (second) of idleness (no packets being sent), > > the mobile network negotiates away the high speed resources (the one > > that enables multimegabit/s transfers) and tries to give it to > > someone else. After approximately 30 seconds, the terminal goes to > > "idle", meaning it has no network resources at all. Next time it > > wants to send something (or the network wants to deliver something > > to it), network resources need to be negotiated again. This can take > > 1-2 seconds and uses battery power of course. It also consumes > > resources in the operator network (because mobility control units > > need to talk to base stations, tunnels need to be re-negotiated > > etc). > > > > Anyhow, my point is that not only is there a benefit in having > > multiple applications wake up at the same time for power reasons > > within the device, there is also a point in having coordination of > > their network access. If a device is running 3 IM programs at the > > same time, it'd be beneficial if they were coordinated in their > > communication with their Internet servers. Same goes for the "check > > for new email" application. If they all were optimized to only wake > > up the network connectivity once every 180 seconds instead of doing > > it when the individual application felt like it, power and other > > resources would be saved by all involved parties. > > This is a good point. Within some limits, the timer-aggregation > changes that have gone into Linux can handle this, but I am not sure > whether or not 180 seconds is within the reasonable boundaries for > timer jitter. this is why operating systems for mobile devices offer heartbeat services... where apps subscribe to and do background work like checking email at "convenient" times. I'm not sure if the OS you use on your desktop has one, but MeeGo and Maemo and I'm pretty sure Android and most other mobile Linux OSes have one. It's a higher level activity alignment layer, well above the kernel. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 1 Aug 2010 18:50 On Sunday, August 01, 2010, Paul E. McKenney wrote: > On Sun, Aug 01, 2010 at 05:41:30PM +0200, Rafael J. Wysocki wrote: > > On Saturday, July 31, 2010, Alan Stern wrote: > > > On Sat, 31 Jul 2010, Paul E. McKenney wrote: .... > > > On Android this goes somewhat farther. IIUC, they want hardly anything > > > to run while the display is powered off. (But my understanding could > > > be wrong.) > > > > Not really. Quite a lot of things happen on these systems while the display > > is off (let alone the periodic battery monitoring on Nexus One :-)). They > > can send things over the network and do similar stuff in that state. > > > > I think the opposite is true, ie. the display is aggressively turned off > > whenever it appears not to be used, because it draws a lot of power. > > Fair enough. It appears to me that Android won't suspend if the display > is on, but I could easily be confused here. That's correct. In fact, Android uses a special mechanism called "early suspend" (or similar) to suspend the display and some other devices before the "real" suspend happens. .... > > > > o Power-naive applications must be prohibited from controlling > > > > the system power state. One acceptable approach is through > > > > use of group permissions on a special power-control device. > > > > > > You mean non-power-aware applications, not power-naive applications. > > > But then the statement is redundant; it follows directly from the > > > definition of "power-aware". > > > > Agreed. > > OK, but I still believe that an enforcement mechanism is required. The requirement is that power-oblivious applications should not participate in deciding whether or not to put the system into a sleep state which is pretty much by definition. > > > > o Statistics of the power-control actions taken by power-aware > > > > applications must be provided, and must be keyed off of program > > > > name. > > > > > > > > o Power-aware applications can make use of power-naive infrastructure. > > > > This means that a power-aware application must have some way, > > > > whether explicit or implicit, to ensure that any power-naive > > > > infrastructure is permitted to run when a power-aware application > > > > needs it to run. > > > > > > > > o When a power-aware application is preventing the system from > > > > shutting down, and is also waiting on a power-naive application, > > > > the power-aware application must set a timeout to handle > > > > the possibility that the power-naive application might halt > > > > or otherwise fail. (Such timeouts are also used to limit the > > > > number of kernel modifications required.) > > > > > > No, this is not a requirement. A power-optimized application would do > > > this, of course, by definition. But a power-aware application doesn't > > > have to. > > > > Agreed. > > Again, this requirement was explicitly called out by the Android folks. Rather, there should be a mechanism allowing PM-driving applications to do that, but they are not required to use that mechanism. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ted Ts'o on 1 Aug 2010 18:50
On Sun, Aug 01, 2010 at 12:12:28PM -0700, Paul E. McKenney wrote: > > I understand that you would prefer that we group applications into > "good" and "bad" categories, but then again, I suspect that most of us > understood that before you posted this message. Given your significant > and well-appreciated contributions to power efficiency over the past > several years, I must confess to be quite disappointed that you failed > to do more than to simply restate your preference. Paul, I very much agree with what you stated later, with respect to doubting whether the whack-a-mole approach to application fixups is workable. Given how many applications screw up using fsync() correctly, to the extent that XFS, ext4, and btrfs all had to agree on a common hueristics to deal with the fact that application programmers are aggressively ignorant, and outnumber the file system developers, I too doubt the general strategy of relying only on application programmers to do the right thing. That's not to say that we shouldn't give up on trying to influence application programmers --- but relying on that as the only strategy seems to depart from the path of wisdom. There is however a much bigger point, which is that it's unfortunately black and white to talk about applications being "good" and "bad". In fact, it's a continuing point of concern I have with the whole qos approach to power management. In fact, power is often something that needs to trade off against performance. For example, an application could aggressively prefetch e-mail messages or web pages that a user _might_ view --- or it could aggressively pre-resolve DNS queries, etc, which might make perfect sense when the device is hooked up to AC mains, but which I might not want to do on when I only have 800mWh worth of battery --- however, if I'm using a laptop with 94,000mWh, maybe I'd be happy if the application was a bit more profligate. So for Arjan to claim that all applications will be held to the same standard, whether they are hooked up to the AC mains, or are limited to 800mWh of battery, or 94,000 mWh worth of power, is vastly oversimplifying the problem. Of *course* if I'm writing an application that will be running in a cloud data center, I'm going to care about power. But I may have different tradeoffs about what might considered acceptible when considering the qualify of user experience I'm delivering to the end-user when I'm connected to AC mains, versus a cell phone battery, versus a 6-cell laptop battery. This brings me back to a major problem I have with the pm_qos approach to power management. It assumes that applications know best, and that they should be free to tell pm_qos subsystem whether they need 0ms latency for wireless. Right now, I can't even query the pm_qos subsystem to see which application is responsible for keeping the wireless on 100% of the time! And even if I could find out, maybe some power management framework should be allowed to give a override to the application's wishes. OK, maybe the Opera web browser is requesting the very best wireless QOS because it wants to beat Chrome on some silly potato benchmark --- well, it's ***stupid*** to say that my power management should be a one-size-fits all because applications should be always as power efficient as possible whether they are connected to AC mains or I have a 800mWh cell phone battery. Worse yet, it's stupid to say that the application should have the last word. Darn it, *I* own the mobile device, and I (or my proxy, which might be the Android OS, or some power manage daemon) should be able to say, "I don't care what the application claimed it wanted for power QOS --- it's not getting more than 100ms wireless latency, and that's final." And note that this is something that might even change over time, or depending on circumstances. Maybe normally I might be willing to let the application be profilgate with power, so that web pages render a bit faster than they might otherwise --- but if I'm on an American Airlines flight which has retrofitted its power jacks to use an AC plug, and I only have a DC adaptor, and my laptop batteries are worn out and only have half their endurance as they used to, I might want to use a more stringent pm_qos than I might otherwise normally allow. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |