From sacadmin Wed Feb 2 15:00:36 2005 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j12N0aSp005176 for ; Wed, 2 Feb 2005 15:00:36 -0800 (PST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.Sun.COM [192.18.42.14]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j12MxZuL026900 for ; Wed, 2 Feb 2005 14:59:35 -0800 (PST) Received: from phys-bos-2.sfbay.sun.com ([129.146.14.24]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j12MxZpv003987 for ; Wed, 2 Feb 2005 14:59:35 -0800 (PST) Received: from sun.com (punchin-sarito.SFBay.Sun.COM [192.9.61.52]) by bos-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2 HotFix 0.05 (built Jan 10 2005)) with ESMTP id <0IBB0044T3VA2NC0@bos-mail1.sfbay.sun.com> for psarc@sac.sfbay; Wed, 02 Feb 2005 14:59:35 -0800 (PST) Date: Wed, 02 Feb 2005 14:59:34 -0800 From: "Terry (Sarito) Whatley" Subject: 2005/067 CPU Power Management independent of autopm vs. 2004/826 To: psarc@sac.sfbay.sun.com Cc: x86power-iteam@Sun.COM, estar-core@Sun.COM Message-id: <42015B56.9010504@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 Status: RO Case 2004/826 "Opteron/Athlon64 Frequency Management" doesn't really need a full case. It is my expectation that after 2005/067 "CPU Power Management independent of autopm" and another fast-track that we are about to file (regarding enabling autopm on X86 workstations) are resolved, we will close 2004/826 as "closed superseded" by the 2 fast-tracks. thanks, Terry (Sarito) Whatley From sacadmin Mon Nov 28 11:37:34 2005 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jASJbYIQ012039 for ; Mon, 28 Nov 2005 11:37:34 -0800 (PST) Received: from nwkes-gis-mail-2.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jASJbXTe014488 for ; Mon, 28 Nov 2005 11:37:33 -0800 (PST) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwkes-gis-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id jASJbSVs009215 for ; Mon, 28 Nov 2005 11:37:28 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IQO00801JMYX100@d1-sfbay-09.sun.com> (original mail from Terry.Whatley@Sun.COM) for PSARC@sac.sfbay.sun.com; Mon, 28 Nov 2005 11:37:28 -0800 (PST) Received: from [192.9.61.52] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IQO00HWWJUG4640@d1-sfbay-09.sun.com>; Mon, 28 Nov 2005 11:37:28 -0800 (PST) Date: Mon, 28 Nov 2005 10:39:41 -0800 From: "Terry (Sarito) Whatley" Subject: 2004/826 Opteron Athlon64 Frequency Management Sender: Terry.Whatley@Sun.COM To: PSARC@sac.sfbay.sun.com Cc: x86power-iteam , estar-core@Sun.COM Message-id: <438B4EED.3040506@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 3204 I'm converting this case to a fast-track. Name: Opteron/Athlon64 Frequency Management Submitter: Mark Haywood (was Andrew Stitcher) Owner: Terry Whatley Interest: x86-power-iteam@sun.com, estar-core@sun.com Status: waiting fast-track 11/30/2005 Background SPARC processors have the capability to reduce power consumption by running at a reduced clock frequency. Support for this was put into Solaris as part of PSARC 1997/326, in order to meet EnergyStar guidelines on SPARC workstations. Essentially the cpu power management driver (us_drv) monitors idle and user cpu utilization percentages, and marks the cpu device idle when the usage could all be handled at the next lower frequency, or raises the power level (frequency) when more speed is needed. Opteron/Athlon64 and some Intel X86 processors can also reduce power consumption by reducing clock frequency and reducing operating voltage. (This goes by the marketing name of PowerNow for AMD processors and SpeedStep for Intel processors). Because Sun did not sell X86 workstations, support for these power management features did not get sufficient priority to get into Solaris. The PROBLEM Solaris needs to support this functionality to extend laptop battery life, and reduce noise and heat for workstations and servers. PROPOSAL 1. Port the SPARC cpu power management driver to x86 This consists mainly of changing how the driver gets its ideas of what frequencies the cpu supports from using the prom property "clock-divisors" to using information provided by ACPI. 2. Port the ppm driver to x86. The SPARC ppm driver handles the co-ordination of devices which share a power domain. In the cpu case, all SPARC cpus must change speed together. In the Opteron/Athlon case, multi-core processors must also change speed together. The ppm driver is modified to get x86 CPU power domain information from ACPI (or other architecture-specific mechanisms) instead of from the ppm.conf file. 3. Add an x86 cpu nexus driver. The SPARC cpus show up as children of the root node. The X86 cpus show up one layer down the tree, so a CPU nexus driver is needed. BINDING: A patch binding is requested. INTERFACES Interfaces Exported: Interface Classification Comments ----------------------------------------------------------------------------- platform/i86pc/kernel/drv/cpunex Project Private x86 CPU Nexus platform/i86pc/kernel/drv/amd64/cpunex driver platform/i86pc/kernel/drv/cpudrv Project Private x86 CPU driver platform/i86pc/kernel/drv/amd64/cpudrv platform/i86pc/kernel/drv/ppm Project Private x86 Platform platform/i86pc/kernel/drv/amd64/ppm Power Management module platform/i86pc/kernel/drv/ppm.conf Project Private Interfaces Imported: Interface Classification Comments ----------------------------------------------------------------------------- ACPI functions Contracted PSARC/2005/085 Project Private From sacadmin Mon Nov 28 12:35:07 2005 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jASKZ6IQ016061 for ; Mon, 28 Nov 2005 12:35:07 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jASKZ4gG004327; Mon, 28 Nov 2005 20:35:04 GMT Received: from 129.150.120.10 (vpn-129-150-120-10.UK.Sun.COM [129.150.120.10]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id jASKYton018213; Mon, 28 Nov 2005 20:35:00 GMT Subject: Re: 2004/826 Opteron Athlon64 Frequency Management From: Darren J Moffat To: "Terry (Sarito) Whatley" Cc: PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@Sun.COM In-Reply-To: <438B4EED.3040506@sun.com> References: <438B4EED.3040506@sun.com> Content-Type: text/plain Organization: Sun Microsystems, Inc. Message-Id: <1133210137.2282.31.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Mon, 28 Nov 2005 20:35:38 +0000 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 333 Does this case provide support for PowerNow and SpeedStep ? or only PowerNow it wasn't clear from the text given what the mail subject is. I assume this is a complete functional replacement for Casper's powernow hacks but a different implementation (ie port of the SPARC one rather than a standalone solution). -- Darren J Moffat From sacadmin Mon Nov 28 12:47:17 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jASKlGIQ017629 for ; Mon, 28 Nov 2005 12:47:17 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jASKlECM014927; Mon, 28 Nov 2005 21:47:14 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jASKlDDk026510; Mon, 28 Nov 2005 21:47:14 +0100 (MET) Message-Id: <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Darren J Moffat cc: "Terry (Sarito) Whatley" , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@Sun.COM Subject: Re: 2004/826 Opteron Athlon64 Frequency Management In-Reply-To: <1133210137.2282.31.camel@localhost> References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> Date: Mon, 28 Nov 2005 21:47:11 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 807 >Does this case provide support for PowerNow and SpeedStep ? >or only PowerNow it wasn't clear from the text given what the >mail subject is. Which PowerNOW and which SpeedStep? There are at least two (three?) variants of PowerNOW and at least two of SpeedStep. While the Powernow variants K7 and K* are relatively close, K6 is not; and the old SpeedStep uses some magic in ICH while the newer variant uses MSRs. VIA C3 Longhaul/Powersaver also uses MSR (Two variants) and there's a new variant in the C7 which ahs a *zero* switch time. And then there's Transmeta's Longrun. >I assume this is a complete functional replacement for Casper's powernow >hacks but a different implementation (ie port of the >SPARC one rather than a standalone solution). Quite. And support for multi CPUs, etc. Casper From sacadmin Mon Nov 28 13:22:55 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jASLMtIQ019691 for ; Mon, 28 Nov 2005 13:22:55 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jASLMlWa017900; Mon, 28 Nov 2005 16:22:47 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jASLMlFg028870; Mon, 28 Nov 2005 16:22:47 -0500 (EST) Subject: Re: 2004/826 Opteron Athlon64 Frequency Management From: Bill Sommerfeld To: Casper.Dik@sun.com Cc: Darren J Moffat , "Terry (Sarito) Whatley" , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@sun.com In-Reply-To: <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1133212966.26753.103.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Mon, 28 Nov 2005 16:22:47 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 867 On Mon, 2005-11-28 at 15:47, Casper.Dik@Sun.COM wrote: > Which PowerNOW and which SpeedStep? ... So, I believe that this project could be considered architecturally complete if it only delivered support for one processor variant (whichever one is our favorite this week...), as long as this doesn't make it harder for this project team or for someone else to backfill other variants...). A question for the project team: how much observability is there into the current frequency, the possible frequencies, and frequency changes? (I'm admittedly unfamiliar with what we currently do on SPARC aside from once seeing some debug output when I was collecting data relating to a different power-management output). I'd hope to see a stable dtrace probe which fires on frequency changes, since dtrace is frequently used to observe system performance... - Bill From sacadmin Mon Nov 28 14:51:20 2005 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jASMpKIQ026107 for ; Mon, 28 Nov 2005 14:51:20 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jASMpKTe002959 for ; Mon, 28 Nov 2005 14:51:20 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jASMpK3F028699 for ; Mon, 28 Nov 2005 15:51:20 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IQO00N01SQI4400@mail-amer.sun.com> (original mail from Mark.Haywood@Sun.COM) for PSARC@sac.sfbay.sun.com; Mon, 28 Nov 2005 15:51:20 -0700 (MST) Received: from [129.148.19.14] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IQO00E1ZSTBO6BH@mail-amer.sun.com>; Mon, 28 Nov 2005 15:51:18 -0700 (MST) Date: Mon, 28 Nov 2005 17:50:47 -0500 From: Mark Haywood Subject: Re: 2004/826 Opteron Athlon64 Frequency Management In-reply-to: <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> Sender: Mark.Haywood@Sun.COM To: Casper.Dik@Sun.COM Cc: Darren J Moffat , "Terry (Sarito) Whatley" , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@Sun.COM Message-id: <438B89C7.7020402@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 1256 Casper.Dik@sun.com wrote: >>Does this case provide support for PowerNow and SpeedStep ? >>or only PowerNow it wasn't clear from the text given what the >>mail subject is. > > > Which PowerNOW and which SpeedStep? This case provides support for PowerNow, the K8 variant. No SpeedStep yet. > There are at least two (three?) variants of PowerNOW and > at least two of SpeedStep. While the Powernow variants K7 and K* > are relatively close, K6 is not; and the old SpeedStep uses > some magic in ICH while the newer variant uses MSRs. The platforms that we are most interested in supporting at the moment are K8. However, support for other variants and SpeedStep should be easy enough to add later. > VIA C3 Longhaul/Powersaver also uses MSR (Two variants) and there's > a new variant in the C7 which ahs a *zero* switch time. > > And then there's Transmeta's Longrun. > > >>I assume this is a complete functional replacement for Casper's powernow >>hacks but a different implementation (ie port of the >>SPARC one rather than a standalone solution). > > > Quite. > > And support for multi CPUs, etc. It's a replacement for Casper's K8 PowerNow support using a different implementation. And yes, it will support multiple CPUs and multi-core. From sacadmin Mon Nov 28 15:12:18 2005 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jASNCIIQ027889 for ; Mon, 28 Nov 2005 15:12:18 -0800 (PST) Received: from nwkes-gis-mail-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jASNCI2f016378 for ; Mon, 28 Nov 2005 15:12:18 -0800 (PST) Received: from d1-sfbay-03.sun.com ([192.18.39.113]) by nwkes-gis-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id jASNCCIU002894 for ; Mon, 28 Nov 2005 15:12:12 -0800 (PST) Received: from conversion-daemon.d1-sfbay-03.sun.com by d1-sfbay-03.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IQO00B01SJGJ900@d1-sfbay-03.sun.com> (original mail from Terry.Whatley@Sun.COM) for PSARC@sac.sfbay.sun.com; Mon, 28 Nov 2005 15:12:12 -0800 (PST) Received: from [192.9.61.52] by d1-sfbay-03.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IQO008SLTSC2J30@d1-sfbay-03.sun.com>; Mon, 28 Nov 2005 15:12:12 -0800 (PST) Date: Mon, 28 Nov 2005 15:12:12 -0800 From: "Terry (Sarito) Whatley" Subject: Re: 2004/826 Opteron Athlon64 Frequency Management In-reply-to: <1133212966.26753.103.camel@thunk> Sender: Terry.Whatley@Sun.COM To: Bill Sommerfeld Cc: Casper.Dik@Sun.COM, Darren J Moffat , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@Sun.COM Message-id: <438B8ECC.3080702@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> <1133212966.26753.103.camel@thunk> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 2214 Bill Sommerfeld wrote: > On Mon, 2005-11-28 at 15:47, Casper.Dik@Sun.COM wrote: > >>Which PowerNOW and which SpeedStep? > > ... > > So, I believe that this project could be considered architecturally > complete if it only delivered support for one processor variant > (whichever one is our favorite this week...), as long as this doesn't > make it harder for this project team or for someone else to backfill > other variants...). That is the plan. We will first deliver support for the variant of PowerNow supported by processors that we are currently shipping in our products (Mark can elaborate), with the ability to add in support for different variants (including SpeedStep variants) with a re-compile. > A question for the project team: how much observability is there into > the current frequency, the possible frequencies, and frequency changes? > (I'm admittedly unfamiliar with what we currently do on SPARC aside from > once seeing some debug output when I was collecting data relating to a > different power-management output). The set of supported frequencies is available in human-readable form in the pm-components(9P) property exported by the driver. It can also be queried (along with the current state (frequency), time idle in the current state, threshold for this transition, source of threshold (whether from default, specified relative to the device, or specified relative to the component), whether pm is enabled on the device, and a few other bits) via (undocumented) ioctls to /dev/pm. There is also a documented ioctl to /dev/pm (both blocking and non-blocking versions) which allows a process to watch all power transitions. This stuff is all part of the pm framework, and is not specific to cpu pm. This was all put in before dtrace existed. > I'd hope to see a stable dtrace probe which fires on frequency changes, > since dtrace is frequently used to observe system performance... This is a good idea, but I don't believe it should be part of this case. It should not be specific to cpu pm, but to power management observability in general, as other power management events (e.g. disk spin-down/spin-up) are also a factor in performance). > - Bill thanks, sarito From sacadmin Tue Nov 29 05:47:50 2005 Received: from localhost.east.sun.com (vpn-129-150-80-8.East.Sun.COM [129.150.80.8]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATDloIQ003866 for ; Tue, 29 Nov 2005 05:47:50 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id jATDmL79005501; Tue, 29 Nov 2005 08:48:21 -0500 (EST) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.4+Sun/8.13.4/Submit) id jATDmK4k005500; Tue, 29 Nov 2005 08:48:20 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: 2004/826 Opteron Athlon64 Frequency Management From: Bill Sommerfeld To: "Terry (Sarito) Whatley" Cc: Casper.Dik@sun.com, Darren J Moffat , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@sun.com In-Reply-To: <438B8ECC.3080702@sun.com> References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> <1133212966.26753.103.camel@thunk> <438B8ECC.3080702@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 29 Nov 2005 08:48:19 -0500 Message-Id: <1133272099.5293.24.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Status: RO Content-Length: 1263 On Mon, 2005-11-28 at 15:12 -0800, Terry (Sarito) Whatley wrote: > It can also be queried (along with the current state (frequency), time > idle in the current state, threshold for this transition, source of > threshold (whether from default, specified relative to the device, or > specified relative to the component), whether pm is enabled on the > device, and a few other bits) via (undocumented) ioctls to /dev/pm. Is there any reason why these ioctls need to remain undocumented? > This stuff is all part of the pm framework, and is not specific to cpu > pm. This was all put in before dtrace existed. dtrace has now been around for a while. The proposed changes will affect the system behavior of existing amd64 systems upgraded to software which includes this project; > This is a good idea, but I don't believe it should be part of this > case. It should not be specific to cpu pm, but to power management > observability in general, as other power management events (e.g. disk > spin-down/spin-up) are also a factor in performance). Please talk to the dtrace team before completely rejecting this suggestion. I believe that adding trace points of this form is relatively straightforward; if it's not, we want to hear about it... - Bill From sacadmin Tue Nov 29 06:00:37 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATE0bIQ004488 for ; Tue, 29 Nov 2005 06:00:37 -0800 (PST) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id jATE0UM11923; Tue, 29 Nov 2005 07:00:30 -0700 (MST) Received: from vpn-129-150-120-25.uk.sun.com ([129.150.120.25]) by barman.uk.sun.com with esmtp (Exim 4.42) id 1Eh62F-0002kl-Ik; Tue, 29 Nov 2005 14:00:46 +0000 Message-ID: <438C5EF6.9070007@sun.com> Date: Tue, 29 Nov 2005 14:00:22 +0000 From: Alan Burlison User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld CC: "Terry (Sarito) Whatley" , Casper.Dik@sun.com, Darren J Moffat , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@sun.com Subject: Re: 2004/826 Opteron Athlon64 Frequency Management References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> <1133212966.26753.103.camel@thunk> <438B8ECC.3080702@sun.com> <1133272099.5293.24.camel@localhost> In-Reply-To: <1133272099.5293.24.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 606 Bill Sommerfeld wrote: >>This is a good idea, but I don't believe it should be part of this >>case. It should not be specific to cpu pm, but to power management >>observability in general, as other power management events (e.g. disk >>spin-down/spin-up) are also a factor in performance). > > Please talk to the dtrace team before completely rejecting this > suggestion. I believe that adding trace points of this form is > relatively straightforward; if it's not, we want to hear about it... And on that front, shouldn't the current status be exported via the kstat mechanism? -- Alan Burlison -- From sacadmin Tue Nov 29 08:20:13 2005 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATGKCIQ009833 for ; Tue, 29 Nov 2005 08:20:13 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jATGJoH0000930; Tue, 29 Nov 2005 11:19:50 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jATGJorH003254; Tue, 29 Nov 2005 11:19:50 -0500 (EST) Subject: Re: 2004/826 Opteron Athlon64 Frequency Management From: Bill Sommerfeld To: Alan Burlison Cc: "Terry (Sarito) Whatley" , Casper.Dik@sun.com, Darren J Moffat , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@sun.com In-Reply-To: <438C5EF6.9070007@sun.com> References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> <1133212966.26753.103.camel@thunk> <438B8ECC.3080702@sun.com> <1133272099.5293.24.camel@localhost> <438C5EF6.9070007@sun.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1133281189.2367.94.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 29 Nov 2005 11:19:50 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 422 On Tue, 2005-11-29 at 09:00, Alan Burlison wrote: > > Please talk to the dtrace team before completely rejecting this > > suggestion. I believe that adding trace points of this form is > > relatively straightforward; if it's not, we want to hear about it... > > And on that front, shouldn't the current status be exported via the > kstat mechanism? Indeed, it should.. And adding new kstats is trivial. - Bill From sacadmin Tue Nov 29 12:23:43 2005 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATKNhIQ029463 for ; Tue, 29 Nov 2005 12:23:43 -0800 (PST) Received: from nwkes-gis-mail-2.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jATKNhTe017405 for ; Tue, 29 Nov 2005 12:23:43 -0800 (PST) Received: from d1-sfbay-01.sun.com ([192.18.39.111]) by nwkes-gis-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id jATKNcVs014187 for ; Tue, 29 Nov 2005 12:23:38 -0800 (PST) Received: from conversion-daemon.d1-sfbay-01.sun.com by d1-sfbay-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IQQ00201C9OA900@d1-sfbay-01.sun.com> (original mail from Terry.Whatley@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 29 Nov 2005 12:23:37 -0800 (PST) Received: from [192.9.61.52] by d1-sfbay-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IQQ0022RGNB2730@d1-sfbay-01.sun.com>; Tue, 29 Nov 2005 12:23:37 -0800 (PST) Date: Tue, 29 Nov 2005 12:23:35 -0800 From: "Terry (Sarito) Whatley" Subject: Re: 2004/826 Opteron Athlon64 Frequency Management In-reply-to: <1133281189.2367.94.camel@thunk> Sender: Terry.Whatley@Sun.COM To: Bill Sommerfeld Cc: Alan Burlison , Casper.Dik@Sun.COM, Darren J Moffat , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@Sun.COM, Tesla Core Message-id: <438CB8C7.90805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> <1133212966.26753.103.camel@thunk> <438B8ECC.3080702@sun.com> <1133272099.5293.24.camel@localhost> <438C5EF6.9070007@sun.com> <1133281189.2367.94.camel@thunk> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 1633 Bill Sommerfeld wrote: > On Tue, 2005-11-29 at 09:00, Alan Burlison wrote: > >>>Please talk to the dtrace team before completely rejecting this >>>suggestion. I believe that adding trace points of this form is >>>relatively straightforward; if it's not, we want to hear about it... >> >>And on that front, shouldn't the current status be exported via the >>kstat mechanism? > > > Indeed, it should.. And adding new kstats is trivial. The issue is not whether these things could be done, nor how difficult they are, but whether they should be a requirement for this case. The point of this case is to bring the X86 cpu pm up to par with the SPARC cpu pm. As observability is an issue, it should be a separate case, and it needs an overall design, not just "stick some observability onto whatever bits happen to be changing". I suspect that one could write a dtrace script now that would give the cpu speed change information. I will undertake to do that. I will commit to filing a one-pager on pm observability. The tesla folks are looking into this (I am part of that group), and I expect a pm observability design to come out of that work (in consultation with the dtrace and FMA folks). I don't think that ad hoc dtrace entries should be cobbled on without a coherent design for observability in the pm system as a whole, which is out of the scope of this case. For kstat, we propose to add "max_clock_MHz" and "current_clock_MHz" to the existing cpu_info kstats (for both SPARC and x86). [Does anybody know what the rules would be for removing/replacing the current "clock_MHz" kstat?]. > - Bill thanks, sarito From sacadmin Tue Nov 29 12:40:26 2005 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATKeQIQ000893 for ; Tue, 29 Nov 2005 12:40:26 -0800 (PST) Received: from nwkes-gis-mail-2.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jATKeQ2f024810 for ; Tue, 29 Nov 2005 12:40:26 -0800 (PST) Received: from d1-sfbay-02.sun.com ([192.18.39.112]) by nwkes-gis-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id jATKeKVs015012 for ; Tue, 29 Nov 2005 12:40:20 -0800 (PST) Received: from conversion-daemon.d1-sfbay-02.sun.com by d1-sfbay-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IQQ00C01C6EMB00@d1-sfbay-02.sun.com> (original mail from Terry.Whatley@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 29 Nov 2005 12:40:20 -0800 (PST) Received: from [192.9.61.52] by d1-sfbay-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IQQ008DSHF85W40@d1-sfbay-02.sun.com>; Tue, 29 Nov 2005 12:40:20 -0800 (PST) Date: Tue, 29 Nov 2005 12:40:19 -0800 From: "Terry (Sarito) Whatley" Subject: Re: 2004/826 Opteron Athlon64 Frequency Management In-reply-to: <1133272099.5293.24.camel@localhost> Sender: Terry.Whatley@Sun.COM To: Bill Sommerfeld Cc: Casper.Dik@Sun.COM, Darren J Moffat , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@Sun.COM Message-id: <438CBCB3.1010106@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> <1133212966.26753.103.camel@thunk> <438B8ECC.3080702@sun.com> <1133272099.5293.24.camel@localhost> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 826 Bill Sommerfeld wrote: > On Mon, 2005-11-28 at 15:12 -0800, Terry (Sarito) Whatley wrote: > >>It can also be queried (along with the current state (frequency), time >>idle in the current state, threshold for this transition, source of >>threshold (whether from default, specified relative to the device, or >>specified relative to the component), whether pm is enabled on the >>device, and a few other bits) via (undocumented) ioctls to /dev/pm. > > > Is there any reason why these ioctls need to remain undocumented? Not unless we plan to replace them with dtrace probes :-). The only known users of them are the ddivs pm tests, so we don't have much experience with them. If we do want to make dtrace the mechanism for accessing that info, then we probably don't want to commit to the ioctls, though. > ... -sarito From sacadmin Tue Nov 29 12:46:51 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATKkpIQ001193 for ; Tue, 29 Nov 2005 12:46:51 -0800 (PST) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id jATKkhM20847; Tue, 29 Nov 2005 13:46:44 -0700 (MST) Received: from vpn-129-150-120-25.uk.sun.com ([129.150.120.25]) by barman.uk.sun.com with esmtp (Exim 4.42) id 1EhCNN-0004gJ-GM; Tue, 29 Nov 2005 20:47:00 +0000 Message-ID: <438CBE2A.7090707@sun.com> Date: Tue, 29 Nov 2005 20:46:34 +0000 From: Alan Burlison User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Terry (Sarito) Whatley" CC: Bill Sommerfeld , Casper.Dik@sun.com, Darren J Moffat , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@sun.com, Tesla Core Subject: Re: 2004/826 Opteron Athlon64 Frequency Management References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> <1133212966.26753.103.camel@thunk> <438B8ECC.3080702@sun.com> <1133272099.5293.24.camel@localhost> <438C5EF6.9070007@sun.com> <1133281189.2367.94.camel@thunk> <438CB8C7.90805@sun.com> In-Reply-To: <438CB8C7.90805@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 577 Terry (Sarito) Whatley wrote: > For kstat, we propose to add "max_clock_MHz" and "current_clock_MHz" to > the existing cpu_info kstats (for both SPARC and x86). min_clock_MHz might be useful as well. > [Does anybody know what the rules would be for removing/replacing the > current "clock_MHz" kstat?]. I suspect a PSARCista will be along in a moment, but I suspect the answer is 'Not without notice'. Why don't you just leave clock_MHz as it is (i.e. the current speed) and add the max/min ones? That way you don't break any existing scripts. -- Alan Burlison -- From sacadmin Tue Nov 29 12:50:54 2005 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATKosIQ001352 for ; Tue, 29 Nov 2005 12:50:54 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jATKoiH0002553; Tue, 29 Nov 2005 15:50:44 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jATKoi5w004537; Tue, 29 Nov 2005 15:50:44 -0500 (EST) Subject: Re: 2004/826 Opteron Athlon64 Frequency Management From: Bill Sommerfeld To: "Terry (Sarito) Whatley" Cc: Alan Burlison , Casper.Dik@sun.com, Darren J Moffat , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@sun.com, Tesla Core In-Reply-To: <438CB8C7.90805@sun.com> References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> <1133212966.26753.103.camel@thunk> <438B8ECC.3080702@sun.com> <1133272099.5293.24.camel@localhost> <438C5EF6.9070007@sun.com> <1133281189.2367.94.camel@thunk> <438CB8C7.90805@sun.com> Content-Type: text/plain Message-Id: <1133297443.2367.300.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 29 Nov 2005 15:50:44 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1499 (two replies in one) On Tue, 2005-11-29 at 15:23, Terry (Sarito) Whatley wrote: > The point of this case is to bring the X86 cpu pm up to par with the > SPARC cpu pm. The existing SPARC cpu pm isn't up to par with the general observability of the rest of the system. > As observability is an issue, it should be a separate case, and it > needs an overall design, not just "stick some observability onto whatever > bits happen to be changing". I've received some offline feedback indicating that the lack of observability is an irritant even to people working on the code.. > For kstat, we propose to add "max_clock_MHz" and "current_clock_MHz" to > the existing cpu_info kstats (for both SPARC and x86). > [Does anybody know what the rules would be for removing/replacing the current > "clock_MHz" kstat?]. I'd expect that we'd be better off adding a new "current_clock_MHz", leaving untouched the existing kstat (which, on sparc, is really the max speed, right?). On Tue, 2005-11-29 at 15:40, Terry (Sarito) Whatley wrote: > > Is there any reason why these ioctls need to remain undocumented? > > Not unless we plan to replace them with dtrace probes :-). given that laundry list of statistics, kstats might be a better way. > The only known users of them are the ddivs pm tests, so we don't have > much experience with them. If we provide documented kstats, some gnome type will be able to go off and write or port an applet which tells you what your cpu's doing. - Bill From sacadmin Tue Nov 29 13:01:22 2005 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATL1MIQ002313 for ; Tue, 29 Nov 2005 13:01:22 -0800 (PST) Received: from nwkes-gis-mail-2.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jATL1MTe008640 for ; Tue, 29 Nov 2005 13:01:22 -0800 (PST) Received: from d1-sfbay-02.sun.com ([192.18.39.112]) by nwkes-gis-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id jATL1GVs016133 for ; Tue, 29 Nov 2005 13:01:16 -0800 (PST) Received: from conversion-daemon.d1-sfbay-02.sun.com by d1-sfbay-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IQQ00E01HLJR500@d1-sfbay-02.sun.com> (original mail from Terry.Whatley@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 29 Nov 2005 13:01:16 -0800 (PST) Received: from [192.9.61.52] by d1-sfbay-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IQQ008KWIE45X40@d1-sfbay-02.sun.com>; Tue, 29 Nov 2005 13:01:16 -0800 (PST) Date: Tue, 29 Nov 2005 13:01:16 -0800 From: "Terry (Sarito) Whatley" Subject: Re: 2004/826 Opteron Athlon64 Frequency Management In-reply-to: <438CBE2A.7090707@sun.com> Sender: Terry.Whatley@Sun.COM To: Alan Burlison Cc: Bill Sommerfeld , casper.dik@Sun.COM, Darren J Moffat , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@Sun.COM, Tesla Core Message-id: <438CC19C.3030305@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> <1133212966.26753.103.camel@thunk> <438B8ECC.3080702@sun.com> <1133272099.5293.24.camel@localhost> <438C5EF6.9070007@sun.com> <1133281189.2367.94.camel@thunk> <438CB8C7.90805@sun.com> <438CBE2A.7090707@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 1091 Alan Burlison wrote: > Terry (Sarito) Whatley wrote: > >> For kstat, we propose to add "max_clock_MHz" and "current_clock_MHz" to >> the existing cpu_info kstats (for both SPARC and x86). > > > min_clock_MHz might be useful as well. OK. >> [Does anybody know what the rules would be for removing/replacing the >> current "clock_MHz" kstat?]. > > > I suspect a PSARCista will be along in a moment, but I suspect the > answer is 'Not without notice'. Why don't you just leave clock_MHz as > it is (i.e. the current speed) and add the max/min ones? That way you > don't break any existing scripts. Since clock speed has been changing on SPARC for years without being shown in "clock_MHz", and there is special code in X86 to map the measured speed to the speed stamped on the chip, I figured clock_MHz really means max. I'm ok with either way, but proposed the conservative way out of leaving the old one unchanged. I'm not sure where one would put a notice about a change, since the actual kstat names do not appear to be documented anywhere. Other opinions? thanks, sarito From sacadmin Tue Nov 29 13:09:48 2005 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATL9lIQ002849 for ; Tue, 29 Nov 2005 13:09:48 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id jATL9ZCM003516; Tue, 29 Nov 2005 22:09:36 +0100 (MET) Received: from holland (room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id jATL9ZDk010674; Tue, 29 Nov 2005 22:09:35 +0100 (MET) Message-Id: <200511292109.jATL9ZDk010674@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Bill Sommerfeld cc: "Terry (Sarito) Whatley" , Alan Burlison , Darren J Moffat , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@Sun.COM, Tesla Core Subject: Re: 2004/826 Opteron Athlon64 Frequency Management In-Reply-To: <1133297443.2367.300.camel@thunk> References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> <1133212966.26753.103.camel@thunk> <438B8ECC.3080702@sun.com> <1133272099.5293.24.camel@localhost> <438C5EF6.9070007@sun.com> <1133281189.2367.94.camel@thunk> <438CB8C7.90805@sun.com> <1133297443.2367.300.camel@thunk> Date: Tue, 29 Nov 2005 22:09:33 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 359 >I'd expect that we'd be better off adding a new "current_clock_MHz", >leaving untouched the existing kstat (which, on sparc, is really the max >speed, right?). Well, that's not how it's interpreted by "psrinfo" (I don't see how I can read "operating at" as anything other than current speed) psrinfo obviously needs to be changed, but still.... Casper From sacadmin Tue Nov 29 13:18:08 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATLI8IQ003308 for ; Tue, 29 Nov 2005 13:18:08 -0800 (PST) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id jATLI2M15059; Tue, 29 Nov 2005 14:18:02 -0700 (MST) Received: from vpn-129-150-120-25.uk.sun.com ([129.150.120.25]) by barman.uk.sun.com with esmtp (Exim 4.42) id 1EhCrf-0004tt-Px; Tue, 29 Nov 2005 21:18:18 +0000 Message-ID: <438CC580.9020500@sun.com> Date: Tue, 29 Nov 2005 21:17:52 +0000 From: Alan Burlison User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Casper.Dik@sun.com CC: Bill Sommerfeld , "Terry (Sarito) Whatley" , Darren J Moffat , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@sun.com, Tesla Core Subject: Re: 2004/826 Opteron Athlon64 Frequency Management References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> <1133212966.26753.103.camel@thunk> <438B8ECC.3080702@sun.com> <1133272099.5293.24.camel@localhost> <438C5EF6.9070007@sun.com> <1133281189.2367.94.camel@thunk> <438CB8C7.90805@sun.com> <1133297443.2367.300.camel@thunk> <200511292109.jATL9ZDk010674@vaticaan.Holland.Sun.COM> In-Reply-To: <200511292109.jATL9ZDk010674@vaticaan.Holland.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 666 Casper.Dik@Sun.COM wrote: >>I'd expect that we'd be better off adding a new "current_clock_MHz", >>leaving untouched the existing kstat (which, on sparc, is really the max >>speed, right?). > > Well, that's not how it's interpreted by "psrinfo" (I don't > see how I can read "operating at" as anything other than current > speed) psrinfo obviously needs to be changed, but still.... I vote (not that I actually have one of course ;-) for pretending that we haven't been lying all along - it seems likely that people have been taking clock_MHz as being the current clock rate, why 'fess up when we could make that actually be the case? -- Alan Burlison -- From sacadmin Tue Nov 29 13:21:07 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.45]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATLL7IQ003467 for ; Tue, 29 Nov 2005 13:21:07 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jATLKpkB012872; Tue, 29 Nov 2005 13:21:06 -0800 (PST) Message-Id: <200511292121.jATLKpkB012872@jurassic.eng.sun.com> Date: Tue, 29 Nov 2005 11:20:03 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2004/826 Opteron Athlon64 Frequency Management To: Terry.Whatley@sun.com, sommerfeld@sun.com Cc: Alan.Burlison@sun.com, Casper.Dik@sun.com, Darren.Moffat@sun.com, PSARC@sac.sfbay.sun.com, x86power-iteam@sun.com, estar-core@sun.com, tesla-core@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1+SMaIltV+/gsEP+VcuclQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 392 I want to avoid the point by point responses, but I've got to say that not allowing this case and the dtrace/kstat issues to be separate is really pushing it. Adding these is strictly a resource/priority issue (as the best practices should make them obviously good). That's not an architectural issue. Filing bugs or contacting managers is a good way to deal with concerns here. - jek3 From sacadmin Tue Nov 29 13:46:25 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATLkOIQ005118 for ; Tue, 29 Nov 2005 13:46:24 -0800 (PST) Received: from [129.146.175.65] (new-sac.SFBay.Sun.COM [129.146.175.65]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jATLkOAe022206; Tue, 29 Nov 2005 13:46:24 -0800 (PST) Message-ID: <438CCCD7.3000201@Sun.Com> Date: Tue, 29 Nov 2005 13:49:11 -0800 From: John Plocher User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20040618 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Burlison , Bill Sommerfeld , casper.dik@Sun.Com, Darren J Moffat , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@Sun.Com, Tesla Core Subject: Re: 2004/826 Opteron Athlon64 Frequency Management Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 247 As far as I can tell, there is no ARC case for the clock_MHz kstat, meaning that it is a Project Private interface that can change at any time without any special handling. Whether it *should* change is, of course, another question :-) -John From sacadmin Tue Nov 29 13:51:40 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATLpeIQ005316 for ; Tue, 29 Nov 2005 13:51:40 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jATLpUcW024642; Tue, 29 Nov 2005 13:51:39 -0800 (PST) Message-Id: <200511292151.jATLpUcW024642@jurassic.eng.sun.com> Date: Tue, 29 Nov 2005 11:50:31 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2004/826 Opteron Athlon64 Frequency Management To: sommerfeld@sun.com, Casper.Dik@sun.com Cc: Terry.Whatley@sun.com, Alan.Burlison@sun.com, Darren.Moffat@sun.com, PSARC@sac.sfbay.sun.com, x86power-iteam@sun.com, estar-core@sun.com, tesla-core@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: glUl+OAm3MRJVxqkqeDeVA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 484 > From: Casper.Dik@sun.com ... > Well, that's not how it's interpreted by "psrinfo" (I don't > see how I can read "operating at" as anything other than current > speed) psrinfo obviously needs to be changed, but still.... Is there any more of a suggestion here beyond that the text from psrinfo is tragically broken? I agree (with Alan) that clock_Mhz really means "clock_Mhz_stamped_on_the_chip". This could be different from reality not only to pm but to overclocking. - jek3 From sacadmin Tue Nov 29 13:59:16 2005 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.36]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATLxFIQ006231 for ; Tue, 29 Nov 2005 13:59:15 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-71.SFBay.Sun.COM [129.150.12.71]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id jATLx7ci027474; Tue, 29 Nov 2005 13:59:14 -0800 (PST) Message-Id: <200511292159.jATLx7ci027474@jurassic.eng.sun.com> Date: Tue, 29 Nov 2005 11:58:11 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: 2004/826 Opteron Athlon64 Frequency Management To: Casper.Dik@sun.com, Alan.Burlison@sun.com Cc: sommerfeld@sun.com, Terry.Whatley@sun.com, Darren.Moffat@sun.com, PSARC@sac.sfbay.sun.com, x86power-iteam@sun.com, estar-core@sun.com, tesla-core@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2BdOfXe31o7GdVSMdGhOpg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1103 > From: Alan Burlison ... > > Well, that's not how it's interpreted by "psrinfo" (I don't > > see how I can read "operating at" as anything other than current > > speed) psrinfo obviously needs to be changed, but still.... > > I vote (not that I actually have one of course ;-) for pretending that > we haven't been lying all along - it seems likely that people have been > taking clock_MHz as being the current clock rate, why 'fess up when we > could make that actually be the case? I don't think we actually know how people have been interpreting this (which poo-poos my suggestion too). Hum,... if they were interpreting it to mean "actual clock rate", wouldn't we have expected a bug from some over-clocker? Nah, an over-clocker wouldn't have the time (cycles?) for that. Seriously, in this case, I think the minimal risk is to keep the implementation (maybe provide a parallel, better name) and alter the (mostly absent) definition. Although I am in awe of Casper for noting the psrinfo "turd", I just can't take it as a serious definition of behavior. - jek3 From sacadmin Tue Nov 29 13:59:45 2005 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jATLxiIQ006249 for ; Tue, 29 Nov 2005 13:59:45 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jATLxeH0025871; Tue, 29 Nov 2005 16:59:40 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id jATLxe1W004756; Tue, 29 Nov 2005 16:59:40 -0500 (EST) Subject: Re: 2004/826 Opteron Athlon64 Frequency Management From: Bill Sommerfeld To: Casper.Dik@sun.com Cc: "Terry (Sarito) Whatley" , Alan Burlison , Darren J Moffat , PSARC@sac.sfbay.sun.com, x86power-iteam , estar-core@sun.com, Tesla Core In-Reply-To: <200511292109.jATL9ZDk010674@vaticaan.Holland.Sun.COM> References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> <1133212966.26753.103.camel@thunk> <438B8ECC.3080702@sun.com> <1133272099.5293.24.camel@localhost> <438C5EF6.9070007@sun.com> <1133281189.2367.94.camel@thunk> <438CB8C7.90805@sun.com> <1133297443.2367.300.camel@thunk> <200511292109.jATL9ZDk010674@vaticaan.Holland.Sun.COM> Content-Type: text/plain Message-Id: <1133301579.2367.310.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 29 Nov 2005 16:59:40 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 578 On Tue, 2005-11-29 at 16:09, Casper.Dik@Sun.COM wrote: > >I'd expect that we'd be better off adding a new "current_clock_MHz", > >leaving untouched the existing kstat (which, on sparc, is really the max > >speed, right?). > > Well, that's not how it's interpreted by "psrinfo" (I don't > see how I can read "operating at" as anything other than current > speed) psrinfo obviously needs to be changed, but still.... nitpick. it actually says: The %s processor operates at %d MHz which implies a fixed frequency rather than the current frequency. - Bill From sacadmin Wed Nov 30 09:31:11 2005 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id jAUHVBIQ005958 for ; Wed, 30 Nov 2005 09:31:11 -0800 (PST) Received: from nwkes-gis-mail-2.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jAUHVA2f006641 for ; Wed, 30 Nov 2005 09:31:10 -0800 (PST) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwkes-gis-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id jAUHV5Vs006765 for ; Wed, 30 Nov 2005 09:31:05 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IQS00L0137KGY00@d1-sfbay-09.sun.com> (original mail from Terry.Whatley@Sun.COM) for PSARC@sac.sfbay.sun.com; Wed, 30 Nov 2005 09:31:05 -0800 (PST) Received: from [192.9.61.52] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IQS00JZF3BTT410@d1-sfbay-09.sun.com>; Wed, 30 Nov 2005 09:31:05 -0800 (PST) Date: Wed, 30 Nov 2005 09:31:04 -0800 From: "Terry (Sarito) Whatley" Subject: Re: 2004/826 Opteron Athlon64 Frequency Management In-reply-to: <1133301579.2367.310.camel@thunk> Sender: Terry.Whatley@Sun.COM To: PSARC@sac.sfbay.sun.com Cc: Bill Sommerfeld , Casper.Dik@Sun.COM, Alan Burlison , Darren J Moffat , x86power-iteam , estar-core@Sun.COM, Tesla Core Message-id: <438DE1D8.4080206@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <438B4EED.3040506@sun.com> <1133210137.2282.31.camel@localhost> <200511282047.jASKlDDk026510@vaticaan.Holland.Sun.COM> <1133212966.26753.103.camel@thunk> <438B8ECC.3080702@sun.com> <1133272099.5293.24.camel@localhost> <438C5EF6.9070007@sun.com> <1133281189.2367.94.camel@thunk> <438CB8C7.90805@sun.com> <1133297443.2367.300.camel@thunk> <200511292109.jATL9ZDk010674@vaticaan.Holland.Sun.COM> <1133301579.2367.310.camel@thunk> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 1754 After offline email discussion with various folks, we propose to change the proposal (in materials/proposal) in the following ways: ... 3. Add an x86 cpu nexus driver. The SPARC cpus show up as children of the root node. The X86 cpus show up one layer down the tree, so a CPU nexus driver is needed. +4. Add cpu_info kstats + + We will keep clock_MHz as is, indicating the max, or "speed" stamped on the +chip. We will add "current_clock_Hz" to indicate the frequency at which the +chip is currently running (same as clock_MHz * 1,000,000 if cpu isn't power +manageable), and we will add "supported_frequencies_Hz" which will be a +delimited string (using KSTAT_DATA_STRING) with a colon-separated list of +supported frequencies in Hz (e.g. "900000:1200000:2000000"). + We propose to use Hz instead of MHz because not all supported SPARC +frequencies are evenly divisible by 1M. + These kstats will be Unstable. And: Interfaces Exported: Interface Classification Comments ----------------------------------------------------------------------------- platform/i86pc/kernel/drv/cpunex Project Private x86 CPU Nexus platform/i86pc/kernel/drv/amd64/cpunex driver platform/i86pc/kernel/drv/cpudrv Project Private x86 CPU driver platform/i86pc/kernel/drv/amd64/cpudrv platform/i86pc/kernel/drv/ppm Project Private x86 Platform platform/i86pc/kernel/drv/amd64/ppm Power Management module platform/i86pc/kernel/drv/ppm.conf Project Private +cpu_info kstat "current_clock_Hz" Unstable +cpu_info kstat "supported_frequencies_Hz" Unstable thanks, sarito From sacadmin Thu Mar 15 11:50:47 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2FIokEI015777 for ; Thu, 15 Mar 2007 11:50:46 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2FIokER008289 for ; Thu, 15 Mar 2007 11:50:46 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2FIof7c002316 for ; Thu, 15 Mar 2007 10:50:41 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JEY00K01KAT2200@d1-sfbay-09.sun.com> (original mail from Terry.Whatley@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 15 Mar 2007 11:50:41 -0700 (PDT) Received: from [192.9.61.52] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JEY002U2KCHWP45@d1-sfbay-09.sun.com>; Thu, 15 Mar 2007 11:50:41 -0700 (PDT) Date: Thu, 15 Mar 2007 11:50:41 -0700 From: "Terry (Sarito) Whatley" Subject: Upate to 2004/826 Opteron Athlon64 Frequency Management (SpeedStep integration first) Sender: Terry.Whatley@Sun.COM To: PSARC@sac.sfbay.sun.com Cc: x86power-iteam Message-id: <45F99581.4000401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 641 We initially intended the interfaces presented in this case to be used first to provide PowerNow (AMD's CPU PM technology) support for Solaris X86. However for technical reasons, the PowerNow project has been delayed and we are now planning on using these same interfaces first to implement Enhanced SpeedStep (Intel's nearly identical CPU PM technology) for Solaris. As the case mentions, the interfaces presented in the case are intended to be used by all Solaris x86 CPU power management technologies and so this conforms to the definition, if not the title, of the case. thanks, Terry (Sarito) Whatley for the x86 pm team