linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Ichilevici de Oliveira <martin.i.oliveira@gmail.com>
To: Vince Weaver <vincent.weaver@maine.edu>, Jiri Olsa <jolsa@redhat.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: Interrupt caused by software events
Date: Fri, 11 Jul 2014 11:20:58 -0300	[thread overview]
Message-ID: <20140711142058.GA27580@gamayun> (raw)
In-Reply-To: <20140709135418.GB5767@krava.redhat.com> <alpine.DEB.2.10.1407091002490.26636@vincent-weaver-1.umelst.maine.edu>

[-- 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 --]

  reply	other threads:[~2014-07-11 14:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2014-07-11 15:26     ` Vince Weaver
2014-07-12 21:15     ` Jiri Olsa
2014-07-13  3:34     ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140711142058.GA27580@gamayun \
    --to=martin.i.oliveira@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=vincent.weaver@maine.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).