[tesla-dev] Code review for T-State support and cpu driverre-structuring

[Li, Aubrey]

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