I started reviewing this a few days ago, but haven't finished yet. I will say that what i've learned over the last few days working with cpudrv gives me some good perspective... :)
Thanks, -Eric 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. > > > 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 > > > >