Hey, I looked at both sunpm.c and us_drv.c (as suggested by sarito). So, if I understand correctly, the code in sunpm.c allows for devices to be put in a lower power level when they exceeded a certain threshold of idle time. They are brought back up again when needed. When we would consider the off state as a power level as well, I believe it is possible to extend sunpm.c so that it handles this off state correctly. This could be using the cpu.c functions you mentioned.
Now, while this can take down the processor when idle, it will be possibly be woken up again by the scheduler very shortly. So that's where the story of the power-aware scheduler comes in. We could for example envision a strategy that works opposite to load balancing. Instead of trying to balance, try to put as many tasks to the currently available (in an active state) processors, and only when a certain condition is reached (not sure yet which parameters, but I think the cpu load, and queue length are of importance, right?) will a sleeping processor be woken up and assigned a task to. For the us_drv.c, if I understand correctly, currently it only supports cpu frequency scaling, and no power states. Is that correct? It says that it is not DDI-compatible. What are the implications of this? There do seem to be us_attach() and us_detach() methods. What exactly does the us stand for? Can these functions be used as an alternative to cpu_add_unit() and _del_unit() for example? Thanks, Thomas On 3/15/07, Eric Saxe <[EMAIL PROTECTED]> 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). > 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
