From: xiakaixu <xiakaixu@huawei.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: <ast@plumgrid.com>, <davem@davemloft.net>, <acme@kernel.org>,
<mingo@redhat.com>, <masami.hiramatsu.pt@hitachi.com>,
<jolsa@kernel.org>, <daniel@iogearbox.net>, <wangnan0@huawei.com>,
<linux-kernel@vger.kernel.org>, <pi3orama@163.com>,
<hekuang@huawei.com>, <netdev@vger.kernel.org>
Subject: Re: [PATCH v6 3/4] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter
Date: Thu, 6 Aug 2015 10:49:26 +0800 [thread overview]
Message-ID: <55C2CB36.9010804@huawei.com> (raw)
In-Reply-To: <20150805135317.GZ18673@twins.programming.kicks-ass.net>
于 2015/8/5 21:53, Peter Zijlstra 写道:
> On Wed, Aug 05, 2015 at 12:04:25PM +0200, Peter Zijlstra wrote:
>> Also, you probably want a WARN_ON(in_nmi()) there, this function is
>> _NOT_ NMI safe.
>
> I had a wee think about that, and I think the below is safe.
>
> (with the obvious problem that WARN from NMI context is not safe)
>
> It does not give you up-to-date overcommit times but your version didn't
> either so I'm assuming you don't need those, if you do need those it
> needs more but we can do that too.
>
> ---
> include/linux/perf_event.h | 1 +
> kernel/events/core.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 54 insertions(+)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 2027809433b3..64e821dd64f0 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -659,6 +659,7 @@ perf_event_create_kernel_counter(struct perf_event_attr *attr,
> void *context);
> extern void perf_pmu_migrate_context(struct pmu *pmu,
> int src_cpu, int dst_cpu);
> +extern u64 perf_event_read_local(struct perf_event *event);
> extern u64 perf_event_read_value(struct perf_event *event,
> u64 *enabled, u64 *running);
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 39753bfd9520..7105d37763c1 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -3222,6 +3222,59 @@ static inline u64 perf_event_count(struct perf_event *event)
> return __perf_event_count(event);
> }
>
> +/*
> + * NMI-safe method to read a local event, that is an event that
> + * is:
> + * - either for the current task, or for this CPU
> + * - does not have inherit set, for inherited task events
> + * will not be local and we cannot read them atomically
> + * - must not have a pmu::count method
> + */
> +u64 perf_event_read_local(struct perf_event *event)
> +{
> + unsigned long flags;
> + u64 val;
> +
> + /*
> + * Disabling interrupts avoids all counter scheduling (context
> + * switches, timer based rotation and IPIs).
> + */
> + local_irq_safe(flags);
s/local_irq_safe/local_irq_save, and I have compiled and tested this function
and it is fine. Will use it in the next set.
Thanks.
> +
> + /* If this is a per-task event, it must be for current */
> + WARN_ON_ONCE((event->attach_state & PERF_ATTACH_TASK) &&
> + event->hw.target != current);
> +
> + /* If this is a per-CPU event, it must be for this CPU */
> + WARN_ON_ONCE(!(event->attach_state & PERF_ATTACH_TASK) &&
> + event->cpu != smp_processor_id());
> +
> + /*
> + * It must not be an event with inherit set, we cannot read
> + * all child counters from atomic context.
> + */
> + WARN_ON_ONCE(event->attr.inherit);
> +
> + /*
> + * It must not have a pmu::count method, those are not
> + * NMI safe.
> + */
> + WARN_ON_ONCE(event->pmu->count);
> +
> + /*
> + * If the event is currently on this CPU, its either a per-task event,
> + * or local to this CPU. Furthermore it means its ACTIVE (otherwise
> + * oncpu == -1).
> + */
> + if (event->oncpu == smp_processor_id())
> + event->pmu->read(event);
> +
> + val = local64_read(&event->count);
> + local_irq_restore(flags);
> +
> + return val;
> +}
> +
> static u64 perf_event_read(struct perf_event *event)
> {
> /*
>
> .
>
next prev parent reply other threads:[~2015-08-06 2:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-04 8:58 [PATCH v6 0/4] bpf: Introduce the new ability of eBPF programs to access hardware PMU counter Kaixu Xia
2015-08-04 8:58 ` [PATCH v6 1/4] bpf: Make the bpf_prog_array_map more generic Kaixu Xia
2015-08-04 8:58 ` [PATCH v6 2/4] bpf: Add new bpf map type to store the pointer to struct perf_event Kaixu Xia
2015-08-04 17:43 ` Alexei Starovoitov
2015-08-05 9:41 ` Peter Zijlstra
2015-08-05 9:39 ` Peter Zijlstra
2015-08-05 9:43 ` Peter Zijlstra
2015-08-04 8:58 ` [PATCH v6 3/4] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter Kaixu Xia
2015-08-04 17:55 ` Alexei Starovoitov
2015-08-05 2:09 ` xiakaixu
2015-08-05 10:04 ` Peter Zijlstra
2015-08-05 10:15 ` Peter Zijlstra
2015-08-05 16:00 ` Alexei Starovoitov
2015-08-05 10:31 ` xiakaixu
2015-08-05 13:53 ` Peter Zijlstra
2015-08-05 13:59 ` Peter Zijlstra
2015-08-05 16:08 ` Alexei Starovoitov
2015-08-05 16:21 ` Peter Zijlstra
2015-08-06 2:49 ` xiakaixu [this message]
2015-08-05 15:59 ` Alexei Starovoitov
2015-08-04 8:58 ` [PATCH v6 4/4] samples/bpf: example of get selected PMU counter value Kaixu Xia
2015-08-05 10:06 ` [PATCH v6 0/4] bpf: Introduce the new ability of eBPF programs to access hardware PMU counter 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=55C2CB36.9010804@huawei.com \
--to=xiakaixu@huawei.com \
--cc=acme@kernel.org \
--cc=ast@plumgrid.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=hekuang@huawei.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=pi3orama@163.com \
--cc=wangnan0@huawei.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.