From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: Paul Mackerras <paulus@samba.org>,
eranian@gmail.com, linux-kernel@vger.kernel.org, mingo@elte.hu,
perfmon2-devel@lists.sf.net,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] perf_events: improve Intel event scheduling
Date: Thu, 07 Jan 2010 11:01:06 +0100 [thread overview]
Message-ID: <1262858466.4049.96.camel@laptop> (raw)
In-Reply-To: <bd4cb8901001070154x84a569t71ac317c95eb4683@mail.gmail.com>
On Thu, 2010-01-07 at 10:54 +0100, Stephane Eranian wrote:
>
> Ok, so I made some progress yesterday on all of this.
>
> The key elements are:
> - pmu->enable() is always called from generic with PMU disabled
> - pmu->disable() is called with PMU possibly enabled
> - hw_perf_group_sched_in() is always called with PMU disabled
>
> I got the n_added logic working now on X86.
>
> I noticed the difference in pmu->enabled() between Power and X86.
> On PPC, you disable the whole PMU. On X86, that's not the case.
>
> Now, I do the scheduling in hw_perf_enable(). Just like on PPC, I also
> move events around if their register assignment has changed. It is not
> quite working yet. I must have something wrong with the read and rewrite
> code.
>
> I will experiment with pmu->enable(). Given the key elements above, I think
> Paul is right, all scheduling can be deferred until hw_perf_enable().
>
> But there is a catch. I noticed that hw_perf_enable() is void. In
> other words, it
> means that if scheduling fails, you won't notice. This is not a problem on PPC
> but will be on AMD64. That's because the scheduling depends on what goes on
> on the other cores on the socket. In other words, things can change between
> pmu->enable()/hw_perf_group_sched_in() and hw_perf_enable(). Unless we lock
> something down in between.
You have to lock stuff, you can't fail hw_perf_enable() because at that
point we've lost all track of what failed.
next prev parent reply other threads:[~2010-01-07 10:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-19 15:03 [PATCH] perf_events: improve Intel event scheduling Stephane Eranian
2009-11-18 16:32 ` Peter Zijlstra
2009-12-11 11:00 ` stephane eranian
2009-12-11 11:59 ` stephane eranian
2009-12-21 15:40 ` Peter Zijlstra
2009-12-21 19:00 ` Stephane Eranian
2009-12-21 19:31 ` Peter Zijlstra
2009-12-21 20:59 ` Stephane Eranian
2009-12-21 21:18 ` Peter Zijlstra
2009-12-22 1:09 ` Paul Mackerras
2009-12-22 1:02 ` Paul Mackerras
2009-12-29 14:47 ` Stephane Eranian
2010-01-07 4:13 ` Paul Mackerras
2010-01-07 8:54 ` Peter Zijlstra
2010-01-07 9:00 ` Peter Zijlstra
2010-01-07 9:54 ` Stephane Eranian
2010-01-07 10:01 ` Peter Zijlstra [this message]
2009-12-22 0:57 ` Paul Mackerras
2009-12-11 14:38 ` Stephane Eranian
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=1262858466.4049.96.camel@laptop \
--to=peterz@infradead.org \
--cc=davem@davemloft.net \
--cc=eranian@gmail.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=perfmon2-devel@lists.sf.net \
/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