On 04/20/10 08:22 PM, Bart Smaalders wrote:
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.)
It goes beyond that. Network performance is another interesting one.
10 GB consumes a lot more power than 1GB, which consumes a lot more
power than 100 Mbps. Most 1G devices support 100 and 10 Mbps, and some
10 G devices support lower speeds as well.
You're "how long can I wait" is not really all that useful a metric in
this situations.
I think like other things, this needs an interface that is expressed at
two levels.
At the first level, its just a coarse assessment of preset settings.
"Maximum Performance", "Balanced", and "Minimum Power Utilization" for
example. (There could be additional levels here, but I suspect that any
more than 5 discrete settings for this would be too many.) One imagines
that this coarse setting could be a Committed interface.
At the second level, you have "Advanced" or "Custom" tunables which
would allow the savvy administrator to tweak every setting. From an ARC
standpoint, I'd probably make these individual tunables Uncommitted or
even Volatile -- subject to change whenever need arises.
-- Garrett
_______________________________________________
pm-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pm-discuss
