OSCON 2009: How Intel Designed Netbooks For Fast Starts (InformationWeek) [LWN.net]

OSCON 2009: How Intel Designed Netbooks For Fast Starts (InformationWeek)

Posted Jul 24, 2009 13:14 UTC (Fri) by mjg59 (subscriber, #23239)
In reply to: OSCON 2009: How Intel Designed Netbooks For Fast Starts (InformationWeek) by arjan
Parent article: OSCON 2009: How Intel Designed Netbooks For Fast Starts (InformationWeek)

The runtime PM story still isn't very compelling. We've got infrastructure for dealing with USB, but not so much on other hardware - the absence of any support in the SCSI layer means we're not able to go anywhere with powering down host controllers and also limits the ability to do any kind of decent autosuspend of USB mass storage. Working with Jesse this week, we've managed to shave something like a Watt off graphics in return for 150 lines or so of code. We're seeing vendors starting to engage in aggressive memory underclocking through SMM code and we don't have any kind of answer to that yet. Hibernation's still an utter disaster, though admittedly that's a rather bigger problem.

(Log in to post comments)

OSCON 2009: How Intel Designed Netbooks For Fast Starts (InformationWeek)

Posted Jul 24, 2009 16:35 UTC (Fri) by jsbarnes (guest, #4096) [Link]

I've been meaning to look at Rafael's new runtime PM support code; my quick glance yesterday wasn't nearly enough (though what I saw looked good).

The main issue I see with power management is that it seems to be mostly driver and subsystem level work (though mostly the former I'm afraid). And it's often not totally trivial; saving & restoring device state for suspend/resume has already proven difficult. Doing it at runtime should give us more test coverage there, but doesn't make the problem easier. Also, doing things like the downclocking we're working on in graphics is great, but it does add more complexity (timer driven state machines) to each driver or subsystem...

I hope that as more vendors start shipping Linux, we'll see people focus on a whole set of drivers at a time (the set of drivers for a given platform). But I expect the experience for users running on platforms where the OEM hasn't made such an effort will always lag.