On Sat, 2010-05-15 at 21:52 +0200, Rafael J. Wysocki wrote: > On Saturday 15 May 2010, tytso@xxxxxxx wrote: > > The examples cited where the things like the Palm Pre, and the Nokia > > N770/800/810 series. #1, what works on one embedded > > chipset/architecture might not work on another, and #2, the battery Pretty much all of the architectures going after this sort of market seem to be taking very similar design decisions here. The high degree of integration on the SoCs kind of forces it since you're always going to end up with at least some things on the CPU sitting around idle so something needs to be done to drive their runtime power cost down. However, this does all require software support and the level of implementation of that you see does vary. > > lifetime on the N770 and N800 (both of which I have) is **appalling** > > **bad**. Hrm. I've got those devices as well and I don't recall the battery life being particularly awful when they weren't actively being used which is the interesting case there. It's been a while but ISTR they compared well enough with the smartphones of their generation. YMMV, of course. I guess the other direction to look at this from is that Android devices seem to have battery lifetimes that are comparable to other smartphones, including Linux based ones, rather than remarkably better than them. There's a reasonable number out there that I've seen, using a range of approaches including both pure runtime PM and also normal suspends initiated from userspace with varying degrees of control over the customisation end users can do on their system. Wakelocks aren't totally going out on a limb in their use of suspend, general systems in this area aren't actually relying purely on runtime PM yet. Where wakelocks do stand out from the other solutions I have seen is that they push the management of the decision to suspend into the kernel. I think it's probably most accurate to say that the thing that what wakelocks are designed to deliver is to make the system more forgiving of power inefficient application code (providing it doesn't just request permission to burn the battery, of course). I can't think of any actual implementations I have seen which do anything special to deal with them. The argument there would I guess be that the impact on battery life provides a fairly strong incentive to the application developers to not do silly things. There's a fairly clear tradeoff there, and neither approach is going to be universally right. > And really, the only semi-technical argument against the opportunistic suspend > feature I've seen so far in this thread is that it _may_ _be_ possible to > achieve the same goal in a different way. If I don't see anything more serious > than that, I will take the patchset and push it to Linus (patches [1-6/8] from > version 7 to be precise, as soon as the changelogs are improved as > requested). Well, the other concerns that *might* be considered technical are the requirement for driver modifications to take wakelocks (personally I'm fairly OK with that - it's not especially pretty but they seem trivial enough so meh) and the userspace ABI that's being created to manage suspend blocking (which I've not even looked at). Like I say, I don't personally object to merging the code at this point - I mostly wanted to provide a broader view on the approaches people are using here. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
