On 04/20/10 19:45, Randy Fishel wrote:
Start by defining how the "new" UI should work on a small set of controls we know well and know will continue to be needed going forward: CPUPM and Suspend/Resume. At least limiting ourselves to things we know well should help shake out potential issues with the interfaces.
Let's not design interfaces based on power management technologies; otherwise you're going to add more knobs (and likely non-orthogonal ones) when new technologies arrive. Correct interface design in this case depends on a simple principle: "Tell the OS what you know." Odds are, the administrator doesn't know about C states, CPUPM or other details about how power control is effected on this particular box. The current interface resulted from a lack of abstraction, and we don't wish to repeat that mistake. When I step on the accelerator on my car, I don't worry about ignition timing, fuel mixture, throttle plate angle or other parameters of engine control; I'm telling the car something very simple - how much horsepower/torque I want now. When I rent a car, I need not worry if it's gas, diesel, electric or hybrid - the driving interface is the same. For power management, we need to arrive at some similar simple parameters that describe the power management of the system, regardless of what mechanisms are available in the hardware to realize that management. Clearly, if power management were instantaneous, we would enable it always and have the system dynamically adjust from 0% to 100% as needed. That's not yet the case on current platforms, but this gives us a hint about something the administrator knows, or at least can estimate: "How long can I afford to wait for 100% power from a step input in load?" (It may be useful to expand this to cpu vs ram vs disk response as well.) A similar metric might well be useful to describe how quickly to go back to sleep. The power management facilities job would be to convert the desired behavior into whatever works on the current platform... - Bart -- Bart Smaalders Solaris Kernel Performance [email protected] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ pm-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pm-discuss
