Hi, I've been looking in more detail at the source code and have some
additional questions now. Let me describe my findings below with
questions interleaved...
In uts/common/os/cpu.c, the functions cpu_online, _offline, _poweron,
_poweroff are closely related to what I want to achieve. I believe
these functions take care of everything necessary, among others
disabling interrupts and migrating threads.
In uts/common/syscall/p_online.c, the p_online{,_internal} functions
call the cpu_online etc. functions to handle the work. In a comment is
stated that these two functions should not be used from within the
kernel.
Q1: is this only because it is actually a syscall, or are there other
objectives against this? It seems to me that the implementation is
useful, so could I copy the code to another place for my
implementation?
I've found some DR implementations that use the cpu_offline etc. functions:
uts/sun4u/starcat/io/drmach.c --> drmach_iocage_cpu_acquire
uts/sun4u/io/sbd_cpu.c --> sbd_pre_release_cpu
uts/common/cpr/cpr_misc.c --> cpr_p_online (I don't think this is a DR
impl., but still it uses cpu_offline)
Q2: I am very confused about the naming and meaning of all these names:
sun4u, sun4v, starcat, safari, serengeti, sarek, .... I suppose it has
some logical structure and meaning, can anyone clarify? What are the
actual processor names? Does the DR capability depend on the
processor, or the system architecture? (I thought this only depends on
the processor).
Q3: In order to implement the processor shutdown from the scheduler,
is it correct that I should use these cpu_offline and cpu_poweroff
functions? Or should I find a DR implementation (which would be a sort
of wrapper, right?) and use that one instead?
This is also complicated by the fact that we might use a (simulated)
architecture that in real-life doesn't support DR.
Q4: also in common/os/cpu.c, there are these kstats entries which seem
to record, among others, the idle time of processors. Can I read these
values from the kernel, or are they only for export to userspace?
Thanks again for the help, Thomas
On 3/25/07, Terry (Sarito) Whatley <[EMAIL PROTECTED]> wrote:
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
