perf: introduce model specific events and AMD IBS
in [Kernel]
|
Prev: [tip:perf/core] perf probe: Fix line range to show end line
Next: Why doesn't W1 sub system support UART implementation as bus master?
From: Peter Zijlstra on 15 Apr 2010 03:50 On Tue, 2010-04-13 at 22:23 +0200, Robert Richter wrote: > This patch series introduces model specific events and impments AMD > IBS (Instruction Based Sampling) for perf_events. I would much rather it uses the ->precise thing PEBS also uses, otherwise we keep growing funny arch extensions and end up with a totally fragmented trainwreck of an ABI. > The general approach is to introduce a flag to mark an event as model > specific. With that flag set a model specific ibs (raw) config value > can be passed to the pmu for setup. When there are ibs samples > available, it is sent back as a raw data sample to the userland. So we > have a raw config value and raw sampling data. This requires the > userland to setup ibs and further extract and process sampling data. > > Patches 1-8 rework and refactor the code to prepare the ibs > implementation. This is done in patches 9-12. > > I will add ibs example code to libpfm4. Please add a valid usecase to tools/perf/ instead. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Richter on 15 Apr 2010 11:20 On 15.04.10 09:44:21, Peter Zijlstra wrote: > On Tue, 2010-04-13 at 22:23 +0200, Robert Richter wrote: > > This patch series introduces model specific events and impments AMD > > IBS (Instruction Based Sampling) for perf_events. > > I would much rather it uses the ->precise thing PEBS also uses, > otherwise we keep growing funny arch extensions and end up with a > totally fragmented trainwreck of an ABI. I agree that an exiting flag could be reused. But the naming 'precise' could be misleading. Maybe we rename it to 'model_spec' or something else that underlines the idea of having model specific setups. > > The general approach is to introduce a flag to mark an event as model > > specific. With that flag set a model specific ibs (raw) config value > > can be passed to the pmu for setup. When there are ibs samples > > available, it is sent back as a raw data sample to the userland. So we > > have a raw config value and raw sampling data. This requires the > > userland to setup ibs and further extract and process sampling data. > > > > Patches 1-8 rework and refactor the code to prepare the ibs > > implementation. This is done in patches 9-12. > > > > I will add ibs example code to libpfm4. > > Please add a valid usecase to tools/perf/ instead. I will also provide an example for tools/perf but reusing libpfm4 was a first quick solution for me. -Robert -- Advanced Micro Devices, Inc. Operating System Research Center email: robert.richter(a)amd.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 21 Apr 2010 08:20 On Thu, 2010-04-15 at 17:16 +0200, Robert Richter wrote: > On 15.04.10 09:44:21, Peter Zijlstra wrote: > > On Tue, 2010-04-13 at 22:23 +0200, Robert Richter wrote: > > > This patch series introduces model specific events and impments AMD > > > IBS (Instruction Based Sampling) for perf_events. > > > > I would much rather it uses the ->precise thing PEBS also uses, > > otherwise we keep growing funny arch extensions and end up with a > > totally fragmented trainwreck of an ABI. > > I agree that an exiting flag could be reused. But the naming 'precise' > could be misleading. Maybe we rename it to 'model_spec' or something > else that underlines the idea of having model specific setups. Right, so I really hate PERF_SAMPLE_RAW, and I'm considering simply removing that for PEBS as well, its just too ugly. If we want the register set we need to work on getting PERF_SAMPLE_REGS in a sensible shape. As to the meaning for ->precise, its meant to convey the counters are not affected by skid and the like, I thought IBS provided exact IPs as well (/me should re-read the IBS docs). The thing with something like ->model_spec and PERF_SAMPLE_RAW is that it doesn't provide a clear model, the user doesn't know what to expect of it, it could be anything. We want the ABI to express clear concepts, and things like lets bypass everything and just dump stuff out to userspace really are to be avoided at all costs. Sadly IBS seems to be an utter trainwreck in the concept department (I'm still struggling how to make a sensible interpretation of the data it gathers). The thing I absolutely want to avoid is the ABI becoming a fragmented trainwreck like oprofile is. Also not using sample_period for the sample period is of course utterly unacceptable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stephane Eranian on 21 Apr 2010 09:30 On Wed, Apr 21, 2010 at 2:11 PM, Peter Zijlstra <peterz(a)infradead.org> wrote: > On Thu, 2010-04-15 at 17:16 +0200, Robert Richter wrote: >> On 15.04.10 09:44:21, Peter Zijlstra wrote: >> > On Tue, 2010-04-13 at 22:23 +0200, Robert Richter wrote: >> > > This patch series introduces model specific events and impments AMD >> > > IBS (Instruction Based Sampling) for perf_events. >> > >> > I would much rather it uses the ->precise thing PEBS also uses, >> > otherwise we keep growing funny arch extensions and end up with a >> > totally fragmented trainwreck of an ABI. >> >> I agree that an exiting flag could be reused. But the naming 'precise' >> could be misleading. Maybe we rename it to 'model_spec' or something >> else that underlines the idea of having model specific setups. > > Right, so I really hate PERF_SAMPLE_RAW, and I'm considering simply > removing that for PEBS as well, its just too ugly. If we want the > register set we need to work on getting PERF_SAMPLE_REGS in a sensible > shape. > I wonder why SAMPLE_RAW went in in the first place, then. What was the justification for it, traces? Okay, so you're suggesting everything is exposed via PERF_SAMPLE_REGS. PEBS does capture machine state which is easily mapped onto PERF_SAMPLE_REGS. Well, that's until you look at PEB-LL on Nehalem where is captures latencies and data addresses. IBS does not capture machine state in the sense of general purpose registers. IBS captures micro-architectural info about an instruction and stores this into a handful of IBS registers. Those could be funneled through PERF_SAMPLE_REGS as well, I believe. But that means, PERF_SAMPLE_REGS would need some configuration bitmask to name the registers of interest, e.g. EAX, EDX, IBSOP_DATA, IBSOP_PHYSAD, and so on. As you pointed out a long time ago, IBS returns to much information to be abstracted easily unless you're willing to drop part of the information it returns, e.g., concentrate on cache miss info only. But this goes back to a point I made early on: there are many usage models, different metrics need different data. You don't want to prevent any usage model. > As to the meaning for ->precise, its meant to convey the counters are > not affected by skid and the like, I thought IBS provided exact IPs as > well (/me should re-read the IBS docs). > By construction it is given that it tracks an instruction. Thus, the IP is always that of the monitored instruction: no skid. The difference, though, it that is not associated with an actual counter+event. IBS keeps its own counter. You can easily create a pseudo event (which is what Robert does in his patch). > The thing with something like ->model_spec and PERF_SAMPLE_RAW is that > it doesn't provide a clear model, the user doesn't know what to expect > of it, it could be anything. > I think we can avoid model_spec. > We want the ABI to express clear concepts, and things like lets bypass > everything and just dump stuff out to userspace really are to be avoided > at all costs. > > Sadly IBS seems to be an utter trainwreck in the concept department (I'm > still struggling how to make a sensible interpretation of the data it > gathers). > Concept is simple: track an instruction (uop) as it traverses the pipeline and gather all sort of micro-architectural info. When the instruction retires, interrupt the CPU and deliver the info via registers. The current implementation is not without problems, but you can already gather useful info such as instrs latencies, data cache misses. Speaking of data cache misses, I believe there may be a way to abstract sampling on cache misses, i.e, capture where they occur, that would work with both IBS and PEBS-LL. That may be a good way to start exposing some of the IBS features. > Also not using sample_period for the sample period is of course utterly > unacceptable. > That is fixed now. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Richter on 21 Apr 2010 12:40
On 21.04.10 14:11:05, Peter Zijlstra wrote: > On Thu, 2010-04-15 at 17:16 +0200, Robert Richter wrote: > > On 15.04.10 09:44:21, Peter Zijlstra wrote: > > > On Tue, 2010-04-13 at 22:23 +0200, Robert Richter wrote: > > > > This patch series introduces model specific events and impments AMD > > > > IBS (Instruction Based Sampling) for perf_events. > > > > > > I would much rather it uses the ->precise thing PEBS also uses, > > > otherwise we keep growing funny arch extensions and end up with a > > > totally fragmented trainwreck of an ABI. > > > > I agree that an exiting flag could be reused. But the naming 'precise' > > could be misleading. Maybe we rename it to 'model_spec' or something > > else that underlines the idea of having model specific setups. > > Right, so I really hate PERF_SAMPLE_RAW, and I'm considering simply > removing that for PEBS as well, its just too ugly. If we want the > register set we need to work on getting PERF_SAMPLE_REGS in a sensible > shape. The ABI should provide hw access to all pmu features. As it is not possible to abstract these features for all models and architectures in the same way and a new feature may work completely different, the only solution I see is to provide a way to write to pmu registers and receive sampling data unfiltered back. For IBS for example the data in a sample does not fit into existing generic events. Making IBS generic also does not help much, since it will not be available on different models or architectures. Introducing event types that will never reused do not need to be generalized, it is better to generalize the way how to handle this kind of events. This is the reason I like the model_spec/raw_config/raw_sample approach. > As to the meaning for ->precise, its meant to convey the counters are > not affected by skid and the like, I thought IBS provided exact IPs as > well (/me should re-read the IBS docs). Yes, the real rip is in the sample, but there is much more data than that. So the rip is only a subset. > The thing with something like ->model_spec and PERF_SAMPLE_RAW is that > it doesn't provide a clear model, the user doesn't know what to expect > of it, it could be anything. > > We want the ABI to express clear concepts, and things like lets bypass > everything and just dump stuff out to userspace really are to be avoided > at all costs. Of course, it could be anything. But this is not the intention. If configs and buffers or close or exactly as the hw i/f, then it is spec'ed and well defined. The user only have to know how to configure a certain hw feature of a special model and how to get data back. This is how IBS is implemented. Maybe this is the same that you have in mind with PERF_SAMPLE_REG? This interface can then be reused for a very different feature and this looks to me like a clear solution. I do not see alternatives. And even if we process the samples in the kernel somehow, in the end we pack it and send it to userspace. > Sadly IBS seems to be an utter trainwreck in the concept department (I'm > still struggling how to make a sensible interpretation of the data it > gathers). That's the point, there is no generalization of this type of data, but still it is useful. -Robert > > The thing I absolutely want to avoid is the ABI becoming a fragmented > trainwreck like oprofile is. > > Also not using sample_period for the sample period is of course utterly > unacceptable. > -- Advanced Micro Devices, Inc. Operating System Research Center email: robert.richter(a)amd.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |