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


Reply via email to