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

[Mark Haywood]

Li, Aubrey wrote:
> 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.
>   

Yeah, that's a possibility. I just hate to over run cpu_info with too 
much data.

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

I sort of continued some of the restructuring that I'd started in the 
cpupm-gate repository, so it should be pretty easy to merge the that 
repository when the time comes. I wouldn't bother rewriting anything 
until we integrate. At that point, I can probably merge the repository 
if you like. If I did the restructuring r

Our current T-state work is based off of onnv_91 at the moment.


>   
>> 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.
>
>   
I figure we'll need a probe for the current T-state. Do we need one for 
the list of supported T-states as well?
> Thanks,
> -Aubrey
> _______________________________________________
> tesla-dev mailing list
> tesla-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
>