Thomas De Schampheleire wrote:
On 3/21/07, Terry (Sarito) Whatley <[EMAIL PROTECTED]> wrote:
sunpm.c does not require modification to handle an "off" power state.
The pm framework considers a power level of 0 to be off.
The us driver doesn't support an off state (doesn't advertise a 0
level in its pm-components property) because on the platforms that
it runs on (SPARC workstations), there is no "off" state of the
processor (no way to turn off the processor).
Frequency scaling is a power state (it greatly reduces power consumption
to reduce the clock frequency). us_drv.c does not handle a 0 power
state (off)
because the hardware it supports can't do it.
The us driver only deals with the power level (frequency) of a cpu.
It was created to allow workstations to meet the EPA's EnergyStar
guidelines by reducing their power consumption. It is not involved
in adding or removing cpus from the system because no workstations
support that functionality (at least in 2000 when it was done--though
I'm not aware of any that do now either--the X86 cpus can't be turned
off either in the current workstations that I know of, they can only
have their frequency and voltage reduced).
Ok, I think I understand. But dynamic reconfiguration on these
machines won't work either then, will it?
No.
The project I am working on does not have the ultimate goal of using a
SPARC processor, we are using it because the simulator has a good
model of it and Solaris has a well established code base for it.
Since we are using a simulator, I believe it *is* possible in our
case, to alter the us driver to allow a processor to get shutdown, if
we imagine the simulated processor does have that possibility. This
would allow us to verify whether the shutdown strategy we implement
does work, and that it does save power. We could estimate the power
savings using the appropriate power model. Afterwards, this code could
be ported to processor architectures that do support shutdown.
You might be able to do this using the us driver, but you'd be violating
a few of its assumptions:
a) that it can determine when to change power states on the basis of cpu
utilization,
(a cpu that is shut off has no utilization, so the logic that is
currently used
to bring the processor to a higher state won't work)
b) that it can make a cross-call to the processor to change its power state
c) that since the cpu continues to run, no other kernel data structures
need to be
modified.
I'm guessing that if you want to do shutdown you wouldn't find the us
driver particularly fruitful as a starting point, since it doesn't take care
of any of the things you'd need to do if the cpu stops responding to
cross-calls
and interrupts. etc (like taking it out of the cpu_ready_set),
it doesn't have any logic to restore the cpu to an operating state
(setting up registers, etc), it doesn't take the processor out of the
set of cpus available to dispatch threads, etc.
We could either alter us_drv so that when trying to go slower than the
current slowest possible speed, the processor gets shut down. Or, for
research purposes, we could disable frequency scaling, and only
support on/off and possible intermediate power states, to be able to
verify the impact of the pure states themselves. I believe we then
would need to write a complete alternate us_drv.
Do you understand the way I think and do you think this is a possible
way?
I think I understand what you want to do. We solved a quite different
problem,
and I suspect that you should probably start from scratch rather than
try to fit
what you want into the frequency scaling driver.
-sarito
Thanks, Thomas
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
