Napanda.Pemmaiah wrote: > Hi, > > Mark and I have modified the CPU driver to add basic T-state support > and we are providing a webrev (see bottom of this mail) for code > review feedback. The intent of the T-state support is simply to allow > the CPU driver > to receive _TPC change notifications as a way of throttling > the processor > speed. This is frequently done on some systems as a passive > cooling mechanism. > As part of this effort we've restructured the CPU driver. The > structure as it exists in Nevada today, doesn't lend itself to > supporting > anything other > than P-states. Mark had already restructured the CPU driver in > the cpupm-gate > repository (where Aubrey and Bill are working on C-state > support) and we > reused much of that code. > > > 1) T-State support > > ACPI T-States provide OSPM, the capability to successfully perform > processor throttling. For more information about T-States, please > refer to the section 8 of the ACPI specification document 3.0b > available at http://www.acpi.info/spec.htm. > > The current T-state implementation just provides support > for handling > ACPI _TPC events(Throttling Present Capabilities). Unlike > the P-state > support, where the CPU driver and PM framework monitor CPU > utilization and change P-states dynamically based on that > utilization, > the CPU driver > will not do any such dynamic monitoring or state changing > of T-States. > > When the CPU driver receives a ACPI _TPC event, it throttles the > processor to the indicated level. Processor and BIOS need to support > T-States for this feature to work. The required ACPI control objects > are _PTC, _TSS, _TPC and _TSD. Details on these objects can > be obtained > by referencing the ACPI Specification. > > _TSS: Defines an array of supported throttling states for a > processor. > > _TSD: Defines the processors which share a T-state dependency (i.e., > which processors need to run at the same T-state). > > _TPC: Defines the maximum allowable T-state the OSPM should > request (i.e., > sets a governor on which T-states the OS should request). > > _PTC: Defines the mehtod by which the OSPM should request > T-state changes > of the processor (i.e., write to an MSR or use system I/O). > > These objects are analogous to the P-state related ACPI > objects, _PCT, > _PSS, _PSD and _PPC.
It might be interesting to add this info to kstat. it's convenient for debug and observation. > > > 2) Restructuring of the CPU driver > > To incorporate the T-State support, the CPU driver had to > be restructured. > Instead of just plugging in T-State related code into the > existing P-state > biased CPU driver, we thought it would be better to do some minor > restructuring of the CPU driver (specifically the x64 > specific pieces) to > give T-states (and later C-states) a more equal footing. > > All CPU driver related code under uts/i86pc/io has been moved to > uts/i86pc/io/cpudrv just for grouping puprposes. Also new > files vendor > specific files have been created to allow for the different > capabilities supported be each vendor. Hmm..., the new infrastureture looks much better. It looks like I have to re-write c-state driver. Which ON revisition/gate is this based on? > > 3) Monitoring > > One area that we have not addressed is monitoring. We're > not aware of > T-state monitoring capabilities in other operating systems, > but think > it might be a reasonable thing to provide. We're wondering > if PowerTOP > might be modified to report on T-states? We'd appreciate > any thoughts > that the folks working on PowerTOP might have on that front. > We definitely can add T-state support in PowerTOP. Please don't forget to add proper dtrace probes in the T-state driver as well as kstat info. Thanks, -Aubrey