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).
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
