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: Arjan van de Ven on 1 Aug 2010 23:10 On Sun, 1 Aug 2010 18:10:06 -0700 "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> wrote: > If I understand you correctly, a key point of agreement between you > and the Android guys is that both the system and the user have some > say over how applications are treated by the system in terms of how > seriously the system takes a given application's requests. > > The Android guys also want the user to have some say about what > applications are permitted to have some control over "I want to go to > <this magic deep idle state>" requests. Does that seem reasonable > to you? I personally think it's one of those things where... well we can get a LONG way automatically (by just observing things); asking the users is very very often just caving in rather than solving the problem. Asking the user should only be done for things the user 1) Can give an intelligent answer to and 2) Are something the user WANTS to be involved in. (rather than 'stupid thing, why don't just do the right thing'.. think the Windows Vista security questions) -- 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: Paul E. McKenney on 1 Aug 2010 23:10 On Sun, Aug 01, 2010 at 03:49:04PM -0700, Arjan van de Ven wrote: > 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. Thank you, good to know! Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arjan van de Ven on 2 Aug 2010 00:10 On Sun, 1 Aug 2010 20:03:04 -0700 "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> wrote: > > 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. > > Unless someone can reliably automate whacking the moles, history is > not on the side of the mole-whackers. I won't say that such > automation is impossible, but only because of all the "impossible" > things in my lifetime that have turned out to be possible. we have a few things going for us here though 1) It's easy to programatically detect the problems 1a) so programmers can detect issues before they ship software, unlike the fsync() thing Ted mentions. History is showing this is at least relatively successful in open source, but not with Adobe's proprietary software such as Flash 2) Users can be made aware of what the bad guys are 3) The business models of many of the mobile apps gives programmers a strong incentive to ship well behaving. The moment your first and second review of your app read "this app was identified as reducing battery life a lot"... your revenues will not go beyond the $1.98.. ... assuming these first two guys didn't refund their app. Since we can detect who the bad guys are, we can also automatically quarantine them for the common cases..... which is good news. I'm a little worried that this whole "I need to block suspend" is temporary. Yes today there is silicon from ARM and Intel where suspend is a heavy operation, yet at the same time it's not all THAT heavy anymore.... at least on the Intel side it's good enough to use pretty much all the time (when the screen is off for now, but that's a memory controller issue more than anything else). I'm pretty sure the ARM guys will not be far behind. -- 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 on 2 Aug 2010 01:10 On Sun, 1 Aug 2010, Arjan van de Ven wrote: > I'm a little worried that this whole "I need to block suspend" is > temporary. Yes today there is silicon from ARM and Intel where suspend > is a heavy operation, yet at the same time it's not all THAT heavy > anymore.... at least on the Intel side it's good enough to use pretty > much all the time (when the screen is off for now, but that's a memory > controller issue more than anything else). I'm pretty sure the ARM guys > will not be far behind. remember that this 'block suspend' is really 'block overriding the fact that there are still runable processes and suspending anyway" having it labeled as 'suspend blocker' or even 'wakelock' makes it sound as if it blocks any attempt to suspend, and I'm not sure that's what's really intended. Itsounds like the normal syspend process would continue to work, just this 'ignore if these other apps are busy' mode of operation would not work. which makes me wonder, would it be possible to tell the normal idle detection mechanism to ignore specific processes when deciding if it should suspend or not? how about only considering processes in one cgroup when deciding to suspend and ignoring all others? David Lang -- 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: Florian Mickler on 2 Aug 2010 01:40
Hi, On Sun, 1 Aug 2010 21:05:48 -0700 Arjan van de Ven <arjan(a)infradead.org> wrote: > I'm a little worried that this whole "I need to block suspend" is > temporary. Yes today there is silicon from ARM and Intel where suspend > is a heavy operation, yet at the same time it's not all THAT heavy > anymore.... at least on the Intel side it's good enough to use pretty > much all the time (when the screen is off for now, but that's a memory > controller issue more than anything else). I'm pretty sure the ARM guys > will not be far behind. I think that the only thing that really matters (longterm) with suspend is that processes don't get scheduled anymore when the system is suspended. Cheers, Flo -- 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/ |