Aubrey, Eric, and I had an email discussion of the c-state driver which I will try to paraphrase here. Here is a list of the pieces being worked on:
1. Detect which c-states are supported. Aubrey is almost done with the work to gather this information parsing ACPI tables. This will be merged in with Mark's workspace. 2. Determine what Solaris needs to do to bring processors into each deeper c-state. This includes tsc/APIC timer re-sync on power up, power aware scheduler, interrupt redistribution (with power awareness), and have a system-wide "policy engine" that may need to be aware of each cpu idle time statistics and c-state latencies. Eric and others have spent time on these. I will see how far they are and may be help out here. 3. Design code that will be aware of c-states, operations needed to make c-state transitions, and estimated cost or latency to enter/exit each c-state. Aubrey is working on this. 4. Design a policy interface in the c-state driver. We should probably have an independent policy engine that can take input from the user regarding which policy they want (maximize performance, max power savings, on battery, etc). We also need some independent code that is aware of the whole system and can coordinate the dispatcher, interrupts, and each individual cpu's idle c-states. We also probably want a testing interface for specifying different idle c-state strategies. We need a way for this individual code to specify to the c-state driver what it should do on each cpu. Regards, Bill Holler
