From hans.rosenfeld at amd.com Wed Jul 2 11:52:26 2008 From: hans.rosenfeld at amd.com (Hans Rosenfeld) Date: Wed, 2 Jul 2008 20:52:26 +0200 Subject: [amd-platform-discuss] changes to the IBS provider interface Message-ID: <20080702185226.GH23291@escobedo.amd.com> While adding missing fields to the sampling data structures, I decided to rationalize the ibs_exec_data structure. I don't think it is interesting for the user from which hardware register a single item of data comes from, so I got rid of the op_data{,2,3}_reg sub-structures and put everything in the ibs_exec_data structure. This means that all existing DTrace scripts using fields from those sub-structures will have to be modified, for instance this line: @exec[execname] = sum(args[0]->op_data3_reg.dcache_miss); will become: @exec[execname] = sum(args[0]->dcache_miss); I have not yet committed this change. I would like to know if there are any objections against this, it may be possible that the sub-structures have a purpose that I'm not aware of. -- %SYSTEM-F-ANARCHISM, The operating system has been overthrown From hans.rosenfeld at amd.com Thu Jul 10 08:57:14 2008 From: hans.rosenfeld at amd.com (Hans Rosenfeld) Date: Thu, 10 Jul 2008 17:57:14 +0200 Subject: [amd-platform-discuss] changes to the IBS provider interface In-Reply-To: <20080702185226.GH23291@escobedo.amd.com> References: <20080702185226.GH23291@escobedo.amd.com> Message-ID: <20080710155714.GM23291@escobedo.amd.com> On Wed, Jul 02, 2008 at 08:52:26PM +0200, Hans Rosenfeld wrote: > I have not yet committed this change. I would like to know if there are > any objections against this, it may be possible that the sub-structures > have a purpose that I'm not aware of. Since nobody seems to worry about this change, I'm just going to commit it :) Hans -- %SYSTEM-F-ANARCHISM, The operating system has been overthrown From Kishore.Pusukuri at Sun.COM Tue Jul 15 19:09:05 2008 From: Kishore.Pusukuri at Sun.COM (Kishore Kumar Pusukuri) Date: Tue, 15 Jul 2008 19:09:05 -0700 Subject: [amd-platform-discuss] AMD Phenom Event names Message-ID: <487D5841.6020005@Sun.COM> Hi, I am Kishore, a summer intern, working on "Adaptive Power Management" project at Sun Labs. For our project, we are using Solaris AMD Phenom quad-core (9750) system. I need to know the mapping between "descriptive event names" and "cryptic event names" of this processor. CPU cycles is a descriptive event name for BU_cpu_clk_unhalted event (i.e. cryptic event name - let us say). So what are the "cryptic event names" of the following "descriptive event names" in case of AMD Phenom (10th family processors)? Please help me. 1. Requests to L2 Cache [TLB fill only] 2. L2 Cache Misses [TLB fill only] 3. Dispatched FPU Operations 4. Retired MMX/FP Instructions And I also required cryptic event names for the following descriptive event names, which are described in the paper "Event-Driven Energy Accounting for Dynamic Thermal Management by Frank Bellosa et al.". I am also attaching that paper. Please see Table 1 in that paper. 5. uop queue writes 6. mem retired 7. memory order buffer load replay 8. LD miss 1L retired Please help me. Thanks. Best, Kishore -------------- next part -------------- A non-text attachment was scrubbed... Name: Bellosa-Weissel-Kellner-Waitz-COLP03-Thermal_Management(2).pdf Type: application/pdf Size: 609822 bytes Desc: not available Url : http://mail.opensolaris.org/pipermail/amd-platform-discuss/attachments/20080715/834e3604/attachment-0001.pdf From boris.ostrovsky at amd.com Wed Jul 16 07:53:38 2008 From: boris.ostrovsky at amd.com (Boris Ostrovsky) Date: Wed, 16 Jul 2008 10:53:38 -0400 Subject: [amd-platform-discuss] AMD Phenom Event names In-Reply-To: <487D5841.6020005@Sun.COM> References: <487D5841.6020005@Sun.COM> Message-ID: <487E0B72.4000005@amd.com> Kishore Kumar Pusukuri wrote: > Hi, > > I am Kishore, a summer intern, working on "Adaptive Power Management" > project at Sun Labs. For our project, we are using Solaris AMD Phenom > quad-core (9750) system. > > I need to know the mapping between "descriptive event names" and > "cryptic event names" of this processor. > > CPU cycles is a descriptive event name for BU_cpu_clk_unhalted event > (i.e. cryptic event name - let us say). > > So what are the "cryptic event names" of the following "descriptive > event names" in case of AMD Phenom (10th family processors)? Please > help me. > > 1. Requests to L2 Cache [TLB fill only] > 2. L2 Cache Misses [TLB fill only] > 3. Dispatched FPU Operations > 4. Retired MMX/FP Instructions The "cryptic" names are specific to Solaris, they are defined in http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/pcbe/opteron_pcbe.c You'd have to match the event masks in that file with what the BIOS and Kernel Developer's Guide (BKDG) specifies (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.pdf). See section 3.14. > > And I also required cryptic event names for the following descriptive > event names, which are described in the paper "Event-Driven Energy > Accounting for Dynamic Thermal Management by Frank Bellosa et al.". I am > also attaching that paper. Please see Table 1 in that paper. > 5. uop queue writes > 6. mem retired > 7. memory order buffer load replay > 8. LD miss 1L retired The paper describes Intel processors, you may have some luck with looking at other files in the same directory (http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/pcbe/). -boris > > Please help me. > > Thanks. > > Best, > Kishore > From hans.rosenfeld at amd.com Thu Jul 24 08:58:31 2008 From: hans.rosenfeld at amd.com (Hans Rosenfeld) Date: Thu, 24 Jul 2008 17:58:31 +0200 Subject: [amd-platform-discuss] using different sample periods with IBS at the same time Message-ID: <20080724155831.GA8934@escobedo.amd.com> Hi, I would like to lift the major limitation of the IBS provider, its inability to support enabling multiple probes with different sampling periods. It can currently only be enabled system-wide, and it only supports one sample period for each the fetch and the exec probes. I thought about how to change that, but the only useful way seems to be extending the provider to allow thread- or process-specific enablements of the probes, in addition to the possibility of system-wide sampling. (Just ignoring the sampling period for new probe activations would be another, very simple-minded approach. I don't know whether this would actually be useful.) These thread- or process-specific probes would be enabled and disabled with the context switch to or from user mode. This would probably require some quite intrusive changes to the context switch mechanism, which would probably trigger a lot of people who would surely be very skeptical about that. Since I currently do not know enough about the DTrace provider API and the context switch code to just implement that, I got some time to request some input on that issue. It is quite possible that this approach completely misses the point of what people actually want to do with the IBS provider, and if thats the case I would like to know before I start any coding :) Hans -- %SYSTEM-F-ANARCHISM, The operating system has been overthrown From Eric.Saxe at Sun.COM Thu Jul 24 10:52:46 2008 From: Eric.Saxe at Sun.COM (Eric Saxe) Date: Thu, 24 Jul 2008 10:52:46 -0700 Subject: [amd-platform-discuss] using different sample periods with IBS at the same time In-Reply-To: <20080724155831.GA8934@escobedo.amd.com> References: <20080724155831.GA8934@escobedo.amd.com> Message-ID: <4888C16E.8000403@sun.com> Hi Hans, (I'm copying perf-discuss, since I think this discussion will probably be of general interest, and the wider forum can probably provide you with feedback about expected use cases). Hans Rosenfeld wrote: > Hi, > > I would like to lift the major limitation of the IBS provider, its > inability to support enabling multiple probes with different sampling > periods. It can currently only be enabled system-wide, and it only > supports one sample period for each the fetch and the exec probes. > > I thought about how to change that, but the only useful way seems to be > extending the provider to allow thread- or process-specific enablements > of the probes, in addition to the possibility of system-wide sampling. > (Just ignoring the sampling period for new probe activations would be > another, very simple-minded approach. I don't know whether this would > actually be useful.) > > These thread- or process-specific probes would be enabled and disabled > with the context switch to or from user mode. This would probably > require some quite intrusive changes to the context switch mechanism, > which would probably trigger a lot of people who would surely be very > skeptical about that. > > Since I currently do not know enough about the DTrace provider API and > the context switch code to just implement that, I got some time to > request some input on that issue. It is quite possible that this > approach completely misses the point of what people actually want to do > with the IBS provider, and if thats the case I would like to know before > I start any coding :) > On the face of it, I wonder how different this problem is from the one faced by the cyclic subsystem. It implements an arbitrary resolution interval timer facility, currently backed by the APIC timer (on x86). The same sort of problem arises when you want to use one APIC timer to implement multiple cyclics (where each cyclic will result in the execution (firing) of a handler at some time interval). It uses a heap for this, where the top of heap represents the next scheduled firing...so when a given cyclic fires, the APIC timer is programmed (in one shot mode) to fire when the next one is due. usr/src/uts/common/os/cyclic.c has some of the best documented code in the kernel, you might be interested in taking a look... Thanks, -Eric From Jonathan.Haslam at Sun.COM Fri Jul 25 07:27:57 2008 From: Jonathan.Haslam at Sun.COM (Jon Haslam) Date: Fri, 25 Jul 2008 15:27:57 +0100 Subject: [amd-platform-discuss] [perf-discuss] using different sample periods with IBS at the same time In-Reply-To: <4888C16E.8000403@sun.com> References: <20080724155831.GA8934@escobedo.amd.com> <4888C16E.8000403@sun.com> Message-ID: <4889E2ED.5030903@sun.com> Hi Hans, Firstly, I think that I'd like to see the IBS provider putback into Solaris so that people can gain real world exposure to it. I understand that, on the surface of it, having just a single probe to play with may seem restrictive but it would be good to see what people can turn up with it in its current form and then expand it after that. I have implemented the CPC provider and it faces the same problem; we have finite hardware so how can we share that around. My first implementation which I aim to putback soon (currently under review) takes exactly the same approach that the IBS provider does in that I don't do any fancy multiplexing of events or virtualisation of counters. Once we've gained some real life use out in the field I think we'll know whether or not this is good enough or if we need to do more. As a side note I spoke to Eric about the possibility of integrating the IBS provider quite some time ago but that's fallen down the queue (for me at least). Someone needs to pick it up and integrate it some time... With regard to virtualising the sampling hardware on a per thread/process basis; I think we need to be careful here as there are several sampling technologies that need to be accommodated. A while ago Russ Blaine kicked off some investigations to look at requirements for a generic sampling framework but I'm not sure what the outcome of that was. Maybe Russ can shed more light on this if he's tuning in here? I think that's quite a piece of work though. Jon. >> I would like to lift the major limitation of the IBS provider, its >> inability to support enabling multiple probes with different sampling >> periods. It can currently only be enabled system-wide, and it only >> supports one sample period for each the fetch and the exec probes. >> >> I thought about how to change that, but the only useful way seems to be >> extending the provider to allow thread- or process-specific enablements >> of the probes, in addition to the possibility of system-wide sampling. >> (Just ignoring the sampling period for new probe activations would be >> another, very simple-minded approach. I don't know whether this would >> actually be useful.) >> >> These thread- or process-specific probes would be enabled and disabled >> with the context switch to or from user mode. This would probably >> require some quite intrusive changes to the context switch mechanism, >> which would probably trigger a lot of people who would surely be very >> skeptical about that. >> >> Since I currently do not know enough about the DTrace provider API and >> the context switch code to just implement that, I got some time to >> request some input on that issue. It is quite possible that this >> approach completely misses the point of what people actually want to do >> with the IBS provider, and if thats the case I would like to know before >> I start any coding :) >> >> > On the face of it, I wonder how different this problem is from the one > faced by the cyclic subsystem. It implements an arbitrary resolution > interval timer facility, currently backed by the APIC timer (on x86). > The same sort of problem arises when you want to use one APIC timer to > implement multiple cyclics (where each cyclic will result in the > execution (firing) of a handler at some time interval). It uses a heap > for this, where the top of heap represents the next scheduled > firing...so when a given cyclic fires, the APIC timer is programmed (in > one shot mode) to fire when the next one is due. > > usr/src/uts/common/os/cyclic.c has some of the best documented code in > the kernel, you might be interested in taking a look... > > Thanks, > -Eric > _______________________________________________ > perf-discuss mailing list > perf-discuss at opensolaris.org >