So this brings up a question that I think I've asked before and not seen an answer to. The discussion here seems to be around a C-state driver, not a CPU driver? Does this mean that the C-state support will be in a driver of its own? Or is it going to be functionality provided by the CPU driver?
Given that Aubrey wanted the CPU driver initialization restructured, I assumed that he was planning on one driver. Thanks, Mark Bill Holler wrote: > 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 > > > > > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev
