On 09/03/08 15:02, Bill Holler wrote: > On 09/ 3/08 02:25 PM, Napanda Pemmaiah wrote: >> Hi Bill, >> >> Since the cpupm-gate is merged with ONNV_97, it has the latest P and >> T-State related code, >> and Aubrey has also resolved all the conflicts in the cpupm-gate >> during the merge and therefore >> there is nothing to remove. >> I assume ONVV_97 should already be in opensolaris repository, but I >> am not very sure about the lag between opensolaris repo and nevada. >> Is there any reason of not wanting to putback into >> ON gate? >> > > Anything we do not know is there should not be put back. ;-) > As far as I know, only new Deep C-State work is in cpupm-gate. It also has powertop related changes, but I don't know if it effects the C-State code changes.
Anup > > Thank you, > Bill > > >> >> Thanks >> Anup >> PS: The current P-State related changes is being done in PAD-gate. >> >> >> On 09/03/08 13:23, Bill Holler wrote: >> >>> Does cpupm-gate have dependecys or shared code with other work >>> such as p-states? Is there code in cpupm-gate that would have to be >>> removed before a OpenSolaris putback of the Deep C-State work? >>> >>> Thank you, >>> Bill >>> >>> >>> On 08/30/08 11:10, Li, Aubrey wrote: >>> >>>> I almost finished the reorganization of c-state driver. This is >>>> for c-state observation only. The system can't enter deep c-state >>>> without Bill's HPET work. Due to cpu driver re-structed recently, >>>> c-state has to follow it. Now I'm making a request for code review. >>>> >>>> The webrev for cstate driver can be found at: >>>> http://cr.opensolaris.org/~aubrey/cstate/ >>>> >>>> The patch is against onnv_97(rev 7367), Changes as follows: >>>> >>>> 1) A kstat member added in cpu_info module. >>>> ------------------ >>>> $kstat -m cpu_info | grep supported_max_cstates >>>> supported_max_cstates 3 >>>> ------snip------ >>>> 2) A kstat module added, named "cpudrv", exporting c-state >>>> latency(us), >>>> the method to enter c-state(FFH, SIO) and Power(mW). We could add >>>> more like the total times of entering each c-state, c-state residency >>>> time, etc >>>> for development and observation. >>>> ---------------- >>>> $kstat -m cpudrv >>>> module: cpudrv instance: 0 name: >>>> c1 class: misc >>>> address_space_id FFixedHW >>>> crtime 24.073615727 >>>> latency 1 >>>> power 1000 >>>> snaptime 262.816570865 >>>> >>>> module: cpudrv instance: 0 name: >>>> c2 class: misc >>>> address_space_id SystemIO >>>> crtime 24.073622285 >>>> latency 1 >>>> power 500 >>>> snaptime 262.81687418 >>>> >>>> module: cpudrv instance: 0 name: >>>> c3 class: misc >>>> address_space_id SystemIO >>>> crtime 24.073627073 >>>> latency 57 >>>> power 100 >>>> snaptime 262.817009506 >>>> ------snip------ >>>> >>>> 3) C-state info is obtained from ACPI _CST objects. So, we can't do >>>> anything >>>> if BIOS doesn't export this object out to OS. >>>> >>>> 4) Currently, we only support c-state on the Nehalem platform. this >>>> check was >>>> added in the driver to support c-state on the Nehalem platfrom only. >>>> >>>> 5) Theoretically, C-state coordination has 3 types. But Nehalem >>>> platform >>>> only >>>> support HW_ALL type. So currently c-state domain creation only support >>>> this type. >>>> And the dependency is determined by the core_id. >>>> >>>> 6) _CST notification handler added to accept dynamically change of >>>> c-state type >>>> and number. >>>> >>>> 7) The idle thread proc pointer "idle_cpu" has been changed to a >>>> per-cpu >>>> function pointer, so that we can support different max cstates on the >>>> different >>>> c-state domain. This has to touch the common code, including SPARC, >>>> I'm >>>> glad to accept a better idle. >>>> >>>> 8) On the early boot, "cp->idle_cpu" is assigned to >>>> "generic_idle_cpu()" >>>> and >>>> then "cpu_idle()" or "cpu_idle_mwait()". During cpudrv attaches, or >>>> _CST >>>> notification event occurs, if deep cstate(C2 or high) support >>>> detected, cp->idle_cpu will be changed to point to >>>> "cpu_acpi_idle()", which >>>> supports to >>>> enter deep c-state. And another shadow pointer(cp->shadow_idle_cpu) >>>> saves >>>> the old "cp->idle_cpu". So that if the next idle type is C1, we don't >>>> need to check >>>> if monitor/mwait supported or not, we call "cp->shadow_idle_cpu" to >>>> enter C1 directly. >>>> >>>> 9) The next c-state type is determined by a prediction algorithm, >>>> based >>>> on the last >>>> c-state residency, if the time is large enough, we consider to enter a >>>> deeper c-state >>>> next time. Oppositely, if the time becomes shorter than the current >>>> c-state latency, >>>> we'll make a demotion to enter a higher c-state next time. >>>> >>>> Any suggestion and comments are greatly appreciated! >>>> >>>> Thanks, >>>> -Aubrey >>>> _______________________________________________ >>>> tesla-dev mailing list >>>> tesla-dev at opensolaris.org >>>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev >>>> >> >> >> > -- Anup Pemmaiah Sun Microsystems
