Hi Thomas,
Thomas De Schampheleire wrote:
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 believe it's because the arguments (and return values) for the
p_online* routines
(the P_* state flags) are meant to communicate processor state information
between the kernel and userland (as they are part of the user/kernel
interface)... where kernel
subsystem should be speaking in terms of cpu_flags (the internal
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?
Well, sun4u and sun4v refer to system architectures. starcat and
serengeti are the code names
of two platforms in the sun4u architecture. We usually don't know when
the platform code is
being developed what the platform marketing name (uname -i) will wind up
being...but the platform
code name does tend to stick around. If it makes you feel any better, it
confuses us (well, at least me)
too...since i'll forget (or not know) what the code name really is for a
given system i'm using (which
is needed for assembling the right stuff for a test kernel ala Install(1)).
What are the
actual processor names?
UltraSPARC * are the processor names, and they have code names just like
the platforms.
Jaguar, Panther, Niagara, etc...
Does the DR capability depend on the
processor, or the system architecture? (I thought this only depends on
the processor).
Probably both I would guess. There's definitely a lot of support needed
by the
architecture to be able to power on, initialize, and bring online a
processor while
the rest of the system has already booted.
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.
I guess it depends on what you want to do. If all you want to do is change
the state of the CPU, then you could probably get away with using most
of the routines in cpu.c with minimal code required in the architecture
callbacks.
If want to be able to actually delete/add processors to the system ala
DR, then you'll
need to implement more. Perhaps the fact that this is simulated is
somewhat of a simplifying
factor (less to do). :)
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?
You can read them. There is a CPU_STATS() macro.
-Eric
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
