Message-Id: <C1242C27-229A-4B98-9C44-29CD20049779@163.com>
Date:	Sat, 18 Jul 2015 07:27:43 +0800
From:	pi3orama <pi3orama@....com>
To:	Alexei Starovoitov <ast@...mgrid.com>
Cc:	kaixu xia <xiakaixu@...wei.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"acme@...nel.org" <acme@...nel.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"a.p.zijlstra@...llo.nl" <a.p.zijlstra@...llo.nl>,
	"masami.hiramatsu.pt@...achi.com" <masami.hiramatsu.pt@...achi.com>,
	"jolsa@...nel.org" <jolsa@...nel.org>,
	"wangnan0@...wei.com" <wangnan0@...wei.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"hekuang@...wei.com" <hekuang@...wei.com>
Subject: Re: [RFC PATCH 0/6] bpf: Introduce the new ability of eBPF programs to access hardware PMU counter



发自我的 iPhone

> 在 2015年7月18日，上午6:56，Alexei Starovoitov <ast@...mgrid.com> 写道：
> 
>> On 7/17/15 3:43 AM, kaixu xia wrote:
>> There are many useful PMUs provided by X86 and other architectures. By
>> combining PMU, kprobe and eBPF program together, many interesting things
>> can be done. For example, by probing at sched:sched_switch we can
>> measure IPC changing between different processes by watching 'cycle' PMU
>> counter; by probing at entry and exit points of a kernel function we are
>> able to compute cache miss rate for a function by collecting
>> 'cache-misses' counter and see the differences. In summary, we can
>> define the begin and end points of a procedure, insert kprobes on them,
>> attach two BPF programs and let them collect specific PMU counter.
> 
> that would be definitely a useful feature.
> As far as overall design I think it should be done slightly differently.
> The addition of 'flags' to all maps is a bit hacky and it seems has few
> holes. It's better to reuse 'store fds into maps' code that prog_array
> is doing. You can add new map type BPF_MAP_TYPE_PERF_EVENT_ARRAY
> and reuse most of the arraymap.c code.

Then we also need another BPF_MAP_TYPE_PERF_EVENT_HASHMAP for events in task context.

> The program also wouldn't need to do lookup+read_pmu, so instead of:
>  r0 = 0 (the chosen key: CPU-0)
>  *(u32 *)(fp - 4) = r0
>  value = bpf_map_lookup_elem(map_fd, fp - 4);
>  count = bpf_read_pmu(value);
> you will be able to do:
>  count = bpf_perf_event_read(perf_event_array_map_fd, index)
> which will be faster.
> note, I'd prefer 'bpf_perf_event_read' name for the helper.

I though that. It makes things much simpler since we won't need care verifier too much. 

I choose current implementation because I think we may need perf event not wrapped in map in future (for example, tracepoints). With the design you suggested in this case we have to create a map with only 1 element in it. Although it is acceptable we can make it a better look. However, let's think that in future.

> 
> Then inside helper we really cannot do mutex, sleep or smp_call,
> but since programs are always executed in preempt disabled
> and never from NMI, I think something like the following should work:
> u64 bpf_perf_event_read(u64 r1, u64 index,...)
> {
>  struct bpf_perf_event_array *array = (void *) (long) r1;
>  struct perf_event *event;
> 
>  if (unlikely(index >= array->map.max_entries))
>     return -EINVAL;
>  event = array->events[index];
>  if (event->state != PERF_EVENT_STATE_ACTIVE)
>     return -EINVAL;
>  if (event->oncpu != raw_smp_processor_id())
>     return -EINVAL;
>  __perf_event_read(event);
>  return perf_event_count(event);
> }
> not sure whether we need to disable irq around __perf_event_read,
> I think it should be ok without.
> Also during store of FD into perf_event_array you'd need
> to filter out all crazy events. I would limit it to few
> basic types first.
> 
> btw, make sure you do your tests with lockdep and other debugs on.
> and for the sample code please use C for the bpf program. Not many
> people can read bpf asm ;)
> 

We still need some perf side code to make a c program work. Perf should create the perf events and put them into map. We post this kernel side code first to see your attitude on the basic design principle we choose. Although the implementation has some bugs, from you and Peter's response I think the user interface we choose is no too much problem, so we can start perf side coding now. Right? After perf side code done you won't see asm code in the example.

Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists