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

[Napanda Pemmaiah]

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