Hi Thomas,
Thomas De Schampheleire wrote:
Hi,
I will be following up this project. So to recapitulate, the aim is to take
down a processor based on a policy implemented in the kernel, and to afterwards
re-enable it.
I believe that psradm is solely a user-space tool, so that would mean we cannot use it from kernel code. p_online looks more suitable for this. By putting the cpu in the P_OFFLINE state, no processor nor interrupts will be executed/handled by this cpu, right?
Generally, yes. Although I recall there are cases (on some systems)
where are offline processor might still process interrupts (I believe
it was on x86). Perhaps someone else can jog my memory. :)
To take the processor down, gavinm suggested that we need to use the dynamic
reconfiguration facility. I have the OpenSolaris Internals book, but it doesn't
really explain how to use it. Is there some other documentation for this, or
could you point me to a place in the source code where I should look?
Ah. :) So DR on x86 doesn't exist yet. DR allows deletion of the CPU
from the system, to the extent where the CPU can be powered off. This
obviously requires support from the hardware. On x86, taking the CPU
offline (where it is essentially parked in the C1 state down in the
idle() loop) is as low as we can go right now.
As a side thought: we are looking to implement this in the kernel, since I suppose this is the only feasible way to have a performant execution. The policy to turn on and off cpu's would require interaction with the dispatcher: when a processor is idle we could take it down in order to save power (of course a more intelligent policy is more useful). Do you agree that the kernel is the only possible or practically feasible way of handling this?
What a coincidence. We've been thinking about this as well. :)
We think that having a power management aware dispatcher is important
for a few reasons:
- Existing performance optimizing dispatcher policy that emphasizes
spreading out load across the system
(optimizing for CMT, for example) tends to minimize availability
of power manageable CPU resources. Having
a "default" policy where the dispatcher considers both throughput
and power efficiency would be better.
- CPU PM policy will be more effective if the dispatcher cooperates.
- The system will perform better (overall) given a PM aware
dispatcher since it won't by trying to schedule things to
run on CPUs that have been clocked down.
Over the next week or so, i'd like to kick off a project to go down the
road of making the dispatcher power aware. Perhaps that
would be a good way for us (and interested others) to collaborate?
An alternative would be for the dispatcher to export some information to
user-space, where the policy would react upon it and then use the psradm
user-space tool to take a processor down. However, I think that at the time the
user-space program has realized that a processor is idle and wants to take it
down, the dispatcher has already dispatched a new task to the processor. So I
believe that the latencies involved with such a strategy are too big. An
advantage of this strategy, however, is that the policy can more easily be
changed, since it doesn't involve recompiling the kernel.
Sure. Or a middle ground might be a kernel module (where necessary).
To what extent are such power management facilities actually already present in
the opensolaris kernel?
The mechanisms for doing frequency / voltage scaling of AMD/Intel CPUs
aren't integrated yet. The idle() loop hooks to bring the CPU into the
C1 state (halt) are there. So a CPU that is offline or idle() will
automatically be brought into a lower power consuming state...although
not as low as one would see using frequency / voltage scaling.
Thanks,
-Eric
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
