Not logged in
Log in now
Create an account
Subscribe to LWN
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
LWN.net Weekly Edition for June 6, 2013
Posted Jun 9, 2011 16:06 UTC (Thu) by mjg59 (subscriber, #23239)
So while there's engineering cost involved in reworking some portions of userspace, there's also a measurable engineering benefit in doing so even if you have wakelocks. The market hasn't really been given an opportunity to decide whether or not that's important yet.
(There's technical mechanisms to force userspace to behave without wakelocks, as long as you can assume a userspace that isn't actually pathological. The engineering involved is probably still fairly minimal. They're also undemonstrated, which is more of a problem. I should really get round to trying to prototype that)
Looking forward to seeing your prototype!
Posted Jun 10, 2011 0:00 UTC (Fri) by PaulMcKenney (subscriber, #9624)
Also, when you say that an Android app taking a wakelock pretty much halves your battery life, you are thinking of an Android app that holds a wakelock indefinitely, as opposed to (for example) acquiring it an then immediately releasing it, correct? If the battery lifetime is halved by an Android app holding the wakelock indefinitely, then the Android folks might reasonably argue that this is evidence that wakelocks doubles battery lifetime.
Posted Jun 10, 2011 0:28 UTC (Fri) by mjg59 (subscriber, #23239)
I honestly haven't investigated Meego's full power management implementation, but the easiest way to implement management of this would be to use the new cgroup timer slack mechanism. You'd still require some sort of userspace-level wakelock implementation, but when no userspace locks are held you extend the timer slack for all untrusted applications out to infinity (or as close as possible). Events will still be implemented in a timely manner, but once a task's finished handling it and hits a select or timer it won't be scheduled again until another event hits.
This ought to handle the case that wakelocks are designed to handle, which is that an aggressive suspend implementation leaves you open to races between your suspend policy and event delivery. It also avoids the problem of using a freezer cgroup, where not all events are delivered through a framework so you still have races.
The main difference between wakelocks and this is that truly pathological applications still hurt you (if something's in a tight loop it'll still be scheduled), but also you have to trust your underlying layers to be correct (ie, never to wake up unless event delivery occurs). Running the current Android implementation in such an environment would result in a measurable decrease in battery life. But if your framework's been designed with this in mind, it means you get the benefits of aggressive suspend without the overhead of maintaining semi-fragile kernel modifications (some of which certainly stand no chance of going upstream).
There's no fundamental reason to think that the Android approach involved less engineering effort than Nokia's, and the long-term outcome should have been pretty similar in terms of ideal-case battery life. My experience is that it's not difficult to ensure that your core code is event driven provided that that's a design goal from the outset. So I don't think this distinction is what led to Nokia ending up so far behind schedule. There's probably more straightforward reasons for that.
Nokia, Android, and Approach to Open Source
Posted Jun 13, 2011 15:23 UTC (Mon) by PaulMcKenney (subscriber, #9624)
Then again, there is a good chance that Nokia's current experience will become a prominent business-school case study. In which case, few will pay attention to what either you or I think about the matter. ;-)
Posted Jun 13, 2011 15:40 UTC (Mon) by mjg59 (subscriber, #23239)
It's interesting to compare to Palm. Their kernel was pretty much stock (there's some additional drivers), and while they didn't take the effort to attempt to upstream stuff they'd probably have had little trouble in doing so. They ended up shipping a sufficiently attractive mobile OS that it achieved their goal of turning a failed company into an acquisition target. Which model were they closer to?
Posted Jun 17, 2011 21:21 UTC (Fri) by oak (guest, #2786)
I might be confusing what's in public MeeGo and "Nokia MeeGo", but if you look at the stuff in the public gitorious repos, you notice that it wasn't just "rebasing everything on top of Qt", but first writing a completely new widget toolkit on top of the Qt GraphicsView (which toolkit seems have appeared first under different name, so maybe even that was partially rewritten). One assumes that apps were started before this new toolkit was at the maturity level of e.g. (over decade old) Qt or Gtk which "can" affect how much time went to writing the apps.
And at some point QML came into picture and now there seems to be yet-another widget toolkit, this time done on top of QML...
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds