* Interrupt caused by software events @ 2014-07-08 14:42 Martin Ichilevici de Oliveira 2014-07-09 13:54 ` Jiri Olsa 2014-07-09 14:05 ` Vince Weaver 0 siblings, 2 replies; 7+ messages in thread From: Martin Ichilevici de Oliveira @ 2014-07-08 14:42 UTC (permalink / raw) To: linux-perf-users [-- Attachment #1: Type: text/plain, Size: 682 bytes --] Hello, I'm learning the perf_events programming interface and I'm not sure if what I'm trying to do is possible. I could only find the perf_event_open documentation, but unfortunately that's not enough for my needs, as it only counts the number of events that happened. I'm looking for a way to determine which instruction caused some events: something similar to what perf annotate does, but in an online fashion. Ideally, I'd like to have some kind of handler that gets called whenever a perf event occurs. Is that even possible? If not, is there any way I could get this information in a real-time way? I'll be using PEBS or IBS events. Thank you, -Martin [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Interrupt caused by software events 2014-07-08 14:42 Interrupt caused by software events Martin Ichilevici de Oliveira @ 2014-07-09 13:54 ` Jiri Olsa 2014-07-09 14:05 ` Vince Weaver 1 sibling, 0 replies; 7+ messages in thread From: Jiri Olsa @ 2014-07-09 13:54 UTC (permalink / raw) To: Martin Ichilevici de Oliveira; +Cc: linux-perf-users On Tue, Jul 08, 2014 at 11:42:42AM -0300, Martin Ichilevici de Oliveira wrote: > Hello, > > I'm learning the perf_events programming interface and I'm not sure if > what I'm trying to do is possible. I could only find the perf_event_open > documentation, but unfortunately that's not enough for my needs, as it > only counts the number of events that happened. > > I'm looking for a way to determine which instruction caused some events: > something similar to what perf annotate does, but in an online fashion. > Ideally, I'd like to have some kind of handler that gets called whenever > a perf event occurs. Is that even possible? If not, is there any way I > could get this information in a real-time way? hi, you could use perf_event_create_kernel_counter interface, check the lockup watchdog in kernel/watchdog.c jirka ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Interrupt caused by software events 2014-07-08 14:42 Interrupt caused by software events Martin Ichilevici de Oliveira 2014-07-09 13:54 ` Jiri Olsa @ 2014-07-09 14:05 ` Vince Weaver 2014-07-11 14:20 ` Martin Ichilevici de Oliveira 1 sibling, 1 reply; 7+ messages in thread From: Vince Weaver @ 2014-07-09 14:05 UTC (permalink / raw) To: Martin Ichilevici de Oliveira; +Cc: linux-perf-users On Tue, 8 Jul 2014, Martin Ichilevici de Oliveira wrote: > I'm looking for a way to determine which instruction caused some events: > something similar to what perf annotate does, but in an online fashion. > Ideally, I'd like to have some kind of handler that gets called whenever > a perf event occurs. Is that even possible? If not, is there any way I > could get this information in a real-time way? Not really sure by what you mean by "real-time", but you can theoretically set up the perf_event mmap buffer with a low threshold, and have it configured to send a signal to your program whenever an event comes in. In theory you can get the PEBS-like info out that way. It's going to have fairly high overhead though, especially if you set the sample rate high. It's even worse if you are trying to get full info on *every* event. That's probably not possible with any even that happens more than a few times a second. Vince ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Interrupt caused by software events 2014-07-09 14:05 ` Vince Weaver @ 2014-07-11 14:20 ` Martin Ichilevici de Oliveira 2014-07-11 15:26 ` Vince Weaver ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: Martin Ichilevici de Oliveira @ 2014-07-11 14:20 UTC (permalink / raw) To: Vince Weaver, Jiri Olsa; +Cc: linux-perf-users [-- Attachment #1: Type: text/plain, Size: 2213 bytes --] On Wed, Jul 09, 2014 at 10:05:55AM -0400, Vince Weaver wrote: > Not really sure by what you mean by "real-time", but you can theoretically > set up the perf_event mmap buffer with a low threshold, and have it > configured to send a signal to your program whenever an event comes in. > In theory you can get the PEBS-like info out that way. It's going to have > fairly high overhead though, especially if you set the sample rate high. On Wed, Jul 09, 2014 at 03:54:18PM +0200, Jiri Olsa wrote: > hi, > you could use perf_event_create_kernel_counter interface, > check the lockup watchdog in kernel/watchdog.c Vince and Jiri, Thank you very much for your replies. I re-read my email and I'm not sure I was clear, so just in case I didn't made myself clear, here's a high-level example of what I'm looking for. /*******************/ /* Gets called whenever my program generates a cache-miss */ void my_func() { unsigned long addr = get_ip_that_generated_event(); printf("A cache-miss occurred at IP: %x!\n", addr); } int main() { struct perf_event_attr pe; pe.type = PERF_TYPE_HARDWARE. pe.config = PERF_COUNT_HW_CACHE_MISSES; ... register_handler(&pe, my_func); // code to be monitored unregister_handler(); return 0; } /*******************/ Every time an event occurs (a cache-miss in my example), my_func should get called. The get_ip_that_generated_event() function should return the Instruction Pointer that generated the event. My impression is that this could be done with a low overhead (other then that introduced by what I do in my_func), because "perf record -e cache-misses ./a.out" can pinpoint with little overhead how many times the event was caused by each instruction. But maybe I'm just missing something. Vince: I'm unsure how to configure the mmap buffer you mentioned, and I couldn't find any examples online. Could you please point me to some reference, or maybe provide a little example? Jiri: I'm under the impression I'd have to be in a kernel module (or in kernel mode in general) to use perf_event_create_kernel_counter(). Is that correct? Thank you once again, -Martin [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Interrupt caused by software events 2014-07-11 14:20 ` Martin Ichilevici de Oliveira @ 2014-07-11 15:26 ` Vince Weaver 2014-07-12 21:15 ` Jiri Olsa 2014-07-13 3:34 ` Andi Kleen 2 siblings, 0 replies; 7+ messages in thread From: Vince Weaver @ 2014-07-11 15:26 UTC (permalink / raw) To: Martin Ichilevici de Oliveira; +Cc: Jiri Olsa, linux-perf-users On Fri, 11 Jul 2014, Martin Ichilevici de Oliveira wrote: > /* Gets called whenever my program generates a cache-miss */ > void my_func() > { > unsigned long addr = get_ip_that_generated_event(); > printf("A cache-miss occurred at IP: %x!\n", addr); > } > > int main() > { > struct perf_event_attr pe; > pe.type = PERF_TYPE_HARDWARE. > pe.config = PERF_COUNT_HW_CACHE_MISSES; > ... > register_handler(&pe, my_func); > // code to be monitored > unregister_handler(); > return 0; > } > /*******************/ > > Every time an event occurs (a cache-miss in my example), my_func should > get called. The get_ip_that_generated_event() function should return the > Instruction Pointer that generated the event. In general you can't do this. Cache misses happen way too often, your program would not be able to keep up, and likely it would be causing cache misses itself. Also you should read up on skid, it's very hard to track an event to an exact IP, although if your CPU has PEBS it's possible with certain limitations. > My impression is that this could be done with a low overhead (other then > that introduced by what I do in my_func), because > "perf record -e cache-misses ./a.out" > can pinpoint with little overhead how many times the event was caused by > each instruction. But maybe I'm just missing something. No, what perf record is doing is sampling. It's getting interrupted say every 100,000 cache misses and reporting the values, and hopefully the ones that trigger are statistically relevant enough to extract the full program behavior. > I'm unsure how to configure the mmap buffer you mentioned, and I > couldn't find any examples online. Could you please point me to some > reference, or maybe provide a little example? There are some examples in my perf_event_tests package. See for example https://github.com/deater/perf_event_tests/blob/master/tests/x86_intel/pebs.c although that example really isn't using PEBS yet, I'm currently working on that code, so beware I might be re-writing and moving around the code in that directory in the next few days. Vince ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Interrupt caused by software events 2014-07-11 14:20 ` Martin Ichilevici de Oliveira 2014-07-11 15:26 ` Vince Weaver @ 2014-07-12 21:15 ` Jiri Olsa 2014-07-13 3:34 ` Andi Kleen 2 siblings, 0 replies; 7+ messages in thread From: Jiri Olsa @ 2014-07-12 21:15 UTC (permalink / raw) To: Martin Ichilevici de Oliveira; +Cc: Vince Weaver, linux-perf-users On Fri, Jul 11, 2014 at 11:20:58AM -0300, Martin Ichilevici de Oliveira wrote: > On Wed, Jul 09, 2014 at 10:05:55AM -0400, Vince Weaver wrote: > > Not really sure by what you mean by "real-time", but you can theoretically > > set up the perf_event mmap buffer with a low threshold, and have it > > configured to send a signal to your program whenever an event comes in. > > In theory you can get the PEBS-like info out that way. It's going to have > > fairly high overhead though, especially if you set the sample rate high. SNIP > > Jiri: > I'm under the impression I'd have to be in a kernel module (or in kernel > mode in general) to use perf_event_create_kernel_counter(). Is that > correct? yep, thats kernel space only jirka ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Interrupt caused by software events 2014-07-11 14:20 ` Martin Ichilevici de Oliveira 2014-07-11 15:26 ` Vince Weaver 2014-07-12 21:15 ` Jiri Olsa @ 2014-07-13 3:34 ` Andi Kleen 2 siblings, 0 replies; 7+ messages in thread From: Andi Kleen @ 2014-07-13 3:34 UTC (permalink / raw) To: Martin Ichilevici de Oliveira; +Cc: Vince Weaver, Jiri Olsa, linux-perf-users Martin Ichilevici de Oliveira <martin.i.oliveira@gmail.com> writes: > > /*******************/ > /* Gets called whenever my program generates a cache-miss */ > void my_func() > { > unsigned long addr = get_ip_that_generated_event(); > printf("A cache-miss occurred at IP: %x!\n", addr); > } This will almost certainly not work with any useful workload. Just compare the overhead of the instrumentation with the total run time. The program will be doing nothing but such interrupts and perf will eventually throttle the interrupts. Besides PEBS is not designed to catch every event anyways. If you really want to instrument all cache misses you most likely want to use some memory trace mechanism and a offline cache model or a simulator. -Andi -- ak@linux.intel.com -- Speaking for myself only ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-07-13 3:34 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-07-08 14:42 Interrupt caused by software events Martin Ichilevici de Oliveira 2014-07-09 13:54 ` Jiri Olsa 2014-07-09 14:05 ` Vince Weaver 2014-07-11 14:20 ` Martin Ichilevici de Oliveira 2014-07-11 15:26 ` Vince Weaver 2014-07-12 21:15 ` Jiri Olsa 2014-07-13 3:34 ` Andi Kleen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).