public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Corey Ashford <cjashfor@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 3/5] perf_counter: rework ioctl()s
Date: Tue, 12 May 2009 09:15:22 -0700	[thread overview]
Message-ID: <4A09A09A.7030009@linux.vnet.ibm.com> (raw)
In-Reply-To: <18953.5194.205862.75538@drongo.ozlabs.ibm.com>

Paul Mackerras wrote:
> Corey Ashford writes:
> 
>> I was seeing that on Power5.  On 5/6/2009, I sent along a test case that was 
>> supposed to duplicate the sequence of operations, without using PAPI, to Peter 
>> Zijlstra, cc'ing you.  However, I was unable to get any signals delivered to 
>> user space with that code, so I was unable to reproduce the problem outside of 
>> the PAPI test case.  I don't know why signal delivery doesn't work with that 
>> test case... I spent quite a lot of time verifying that it was doing the right 
>> thing, but could never get it to work.
> 
> I tried your test program out today, with the ioctl calls changed to
> add an extra 0 argument, like this:
> 
>    ioctl(fd[0], PERF_COUNTER_IOC_ENABLE, 0);
> 
> and similarly for the disable call.  It all seemed to be fine.  There
> is still a little problem with enabling counters - it doesn't happen
> right away.  I have a patch to fix that, which I'll send out, and with
> that patch I get:
> 
> # ./test_group_disable 
> evt[0].config = 0
> evt[1].config = 4
> group_leader = -1
> evt[i].wakeup_events = 0
> successfully opened evt[0].  fd[0] = 3
> group_leader = 3
> evt[i].wakeup_events = 0
> successfully opened evt[1].  fd[1] = 4
> successfully attached signal handler
> fd 3's mmap buffer is located at 0xfffab4b3000
> successfully tuned up fd 3
> fd 4's mmap buffer is located at 0xfffab4aa000
> successfully tuned up fd 4
> enable was successful
> CYCLES: 20904
> BRANCHES: 2413
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 4
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 4
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 4
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> signal received while counters are enabled. fd = 3
> disable was successful
> CYCLES: 180149676
> BRANCHES: 30030826
> CYCLES: 180149676
> BRANCHES: 30030826
> CYCLES data_head: 141b0
> BRANCHES data_head: 35a0
> #
> 
> So clearly it is getting signals when the leader is enabled, one per
> page of events, and not when the leader is disabled.  I notice you
> have evt[].wakeup_events set to 0, which is presumably why we don't
> get more signals than we do.

Interesting. Thanks for finding that ioctl error!  That really had me 
stumped.

Another hypothesis is that the old PAPI code would open, mmap, close, 
then reopen, and mmap again.  I wonder if because I wasn't munmap'ing 
before the close, that I got some strange behavior from the kernel. 
I'll try that today with that test case.

Thanks!

- Corey



  reply	other threads:[~2009-05-12 16:17 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-08 16:52 [PATCH 0/5] pending patches Peter Zijlstra
2009-05-08 16:52 ` [PATCH 1/5] hrtimer: per-cpu cached values of ktime Peter Zijlstra
2009-05-08 23:10   ` Andrew Morton
2009-05-09 19:45   ` Linus Torvalds
2009-05-09 19:59     ` Peter Zijlstra
2009-05-08 16:52 ` [PATCH 2/5] perf_counter: optimize perf_counter_task_tick() Peter Zijlstra
2009-05-08 18:39   ` [tip:perfcounters/core] " tip-bot for Peter Zijlstra
2009-05-08 16:52 ` [PATCH 3/5] perf_counter: rework ioctl()s Peter Zijlstra
2009-05-08 18:39   ` [tip:perfcounters/core] " tip-bot for Peter Zijlstra
2009-05-11  1:29   ` [PATCH 3/5] " Paul Mackerras
2009-05-11 15:12     ` Peter Zijlstra
2009-05-12  6:24       ` Paul Mackerras
2009-05-11 18:12     ` Corey Ashford
2009-05-11 20:52       ` Paul Mackerras
2009-05-11 22:37         ` Corey Ashford
2009-05-12  6:16           ` Paul Mackerras
2009-05-12 16:15             ` Corey Ashford [this message]
2009-05-12 22:18               ` Paul Mackerras
2009-05-12 22:51                 ` Corey Ashford
2009-05-11 23:58   ` Arnd Bergmann
2009-05-12  6:11     ` Peter Zijlstra
2009-05-12  6:22       ` Paul Mackerras
2009-05-12  6:27         ` Peter Zijlstra
2009-05-12  7:10           ` Peter Zijlstra
2009-05-12  7:52             ` Arnd Bergmann
2009-05-12 10:59               ` [PATCH] perf_counter: fix ioctl()s Peter Zijlstra
2009-05-12 11:21             ` [PATCH 3/5] perf_counter: rework ioctl()s Paul Mackerras
2009-05-08 16:52 ` [PATCH 4/5] perf_counter: PERF_RECORD_CONFIG Peter Zijlstra
2009-05-08 18:39   ` [tip:perfcounters/core] perf_counter: add PERF_RECORD_CONFIG tip-bot for Peter Zijlstra
2009-05-08 16:52 ` [PATCH 5/5] perf_counter: PERF_RECORD_CPU Peter Zijlstra
2009-05-08 18:40   ` [tip:perfcounters/core] perf_counter: add PERF_RECORD_CPU tip-bot for Peter Zijlstra

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=4A09A09A.7030009@linux.vnet.ibm.com \
    --to=cjashfor@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=tglx@linutronix.de \
    /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