Eric Saxe wrote:
Hi Thomas,
Thomas De Schampheleire wrote:
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.
I don't think I mentioned this before, but the architecture we are
currently targeting is SPARC. DR does exist on that, right?k
Right. On the SPARC based systems where DR is possible, there are
kernel DR modules that implement DR platform support for system
boards, I/O, etc. cfgadm(1M) is the command that can be used to do DR
of systems components. cfgadm has a number of "plugins" that do the
ioctl(2)s to the DR kernel modules. For example, take a look at
cfgadm_sbd(1M) man page. There is also a set of interfaces (see
config_admin(3CFGADM). The DR drivers handle the platform specific
aspects of DR, and call into the platform independent portions of the
kernel to "delete" or "add" CPUs to/from the system. (See
cpu_add_unit() / cpu_del_unit()) in cpu.c.
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 preading 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 nd
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.
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?
A collaboration would certainly be interesting and useful. However
there are a few things that come to mind:
- I am not sure whether this would be architecture-specific. The
dispatcher code is common, but power management would probably not...
If you are looking into x86 and I'm into SPARC, then this could
either be a problem, or complementary.
The mechanisms at play for doing CPU power management seem to be
platform specific. The policies and abstractions relating to the
implementation of the policies i'm looking to make platform
independent. Ideally, you would want to be able to apply the same
policy in the same way regardless of what the hardware looks like.
- Timeline: my work is in the context of a master thesis, which
should be finished before July 2007. By then, the actual
implementation should hopefully be already finished for some time so
I have the time to concentrate on writing the report.
I am not sure how long a complete implementation would take, or which
timeline you had in mind. In case yours is much longer than, say,
May, then we might need to keep separate projects (with of course the
possibility to communicate).
What we have in mind is a bit longer term, I think. But I think there
is still opportunity for collaboration.
- The purpose of my thesis project is to implement a periodic
shutdown of processors in OpenSolaris: each period (period length is
a parameter) the idleness of all processors will be evaluated and
idle processors will be taken offline). The whole idea is to save
energy for battery-powered devices.
This sounds similar to what's currently done for current SPARC desktop
power management, except the processors aren't shutdown, but are
brought into a lower power consuming state. That code also looks at
the idleness of system's CPUs, power managing them lower when idle.
(See common/os/sunpm.c), and power.conf(4).
Also of interest would be sun4u/io/us_drv.c, which implements the
cpu-specific part of this.
-sarito
Obviously, implementing this is much more specific than creating a
complete well-written power-aware scheduler. Due to my time
constraints, the latter could be unfeasible for me to cooperate on. I
think it all depends on your plans and timeline.
Let's keep in touch. Depending on what you want to do, you might be
able to leverage some of our work in progress.
Thanks,
-Eric
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
