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