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 >
