Messages in this thread | | | Date | Thu, 20 May 2010 14:13:43 +0200 | Subject | Re: [PATCH 1/7] perf: introduce raw_type attribute to specify the type of a raw sample | From | Stephane Eranian <> |
| |
On Thu, May 20, 2010 at 12:37 PM, Peter Zijlstra <peterz@infradead.org> wrote: > On Thu, 2010-05-20 at 11:42 +0200, Stephane Eranian wrote: > >> > For Instruction-Fetch: > >> > 32:47 latency (r/w) > >> Your are mixing output and input parameters. >> >> The only input parameters you have are: >> - sample-period, enable, random >> The rest is output only. > > Ah, my bad, I thought it was a r/w field. > >> > encode these IBS things as: >> > >> > 0x87 Instruction Fetch Stall -- Ins-Fetch >> > 0xC0 Retired Instructions -- Ins-Exec >> > >> I think those events do not map to the behavior of IBS. We have >> add that discussion before. > > Hrm,. so there are no regular events that count the same thing as the > IBS things? That really sucks. > > So yeah, you might as well expose it as a whole separate PMU using Lin's > stuff.
What's wrong with creating pseudo-events for IBS? We'd have to pick two unused event codes. That would have the advantage of making it explicit you're using IBS. I think we could still use the precise_ip field if people are only interested in the IP. They would use PERF_SAMPLE_RAW if they need more.
> >> > The Ins-Exec will have to re-construct the actual event->count by adding >> > sample-period on each interrupt, as it seems we lack an actual counter >> > in hardware. >> > >> For what? counting mode? > > Yeah, events are supposed to count. > IBS is a sampling only feature. I suspect it would be okay to return 0 here or do as you said, count the number of IBS interrupts and multiply by the sampling period.
>> > Furthermore, these counters will have to deal with sample-period > 2^16 >> > by 'ignoring' interrupts until we get ->period_left down to 0. >> > >> Well, it's not 2^16, it's 2^20 but bottom 4 bits must be zero. >> What about simply failing perf_event_open() is sample_period does not fit the >> constraint? > > Why, its simple enough to ignore a few interrupts, we do the same for > all other implementations. > >> > The extra data could possibly be exposed through attaching non-sampling >> > group events and using SAMPLE_READ, like L1-misses, although >> > reconstructing the count from just one bit seems 'interesting'. >> > >> > The IbsFetchLinAd/IbsOpRip would go straight into PERF_SAMPLE_IP by >> > replacing pt_regs->ip I guess. >> > >> > IbsDcLinAd goes into PERF_SAMPLE_ADDR >> > >> What about the rest, the TLB, alignment, data sources? > > Dunno, reconstruct sensible counters? Surely the software that uses IBS > does something useful with that data? What does libpfm do with the IBS > data? > The common usage model is you gather the IBSop data (all of it), you save samples into a file and then you have scripts that extract whatever fields they need to compute the metric you want. For instance, if you want data cache misses you extract [IP, data address, data source, miss latency], if you care about instruction latencies, you extract [IP, tag2ret, comp2ret], and so on.
Libpfm does not handle IBS output. Its goal is to help applications setup the events/counters. With perf_events, it does the mapping from symbolic event names+attributes -> struct perf_event_attr. It does not make any perf_event syscalls for you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |