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. 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. 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. The webrev for these changes can be found at: http://cr.opensolaris.org/~mhaywood/tstate/ Your comments will be greatly appreciated. Thanks Anup -- Anup Pemmaiah Sun Microsystems
