On 7/17/15 4:27 PM, pi3orama wrote:
Then we also need another BPF_MAP_TYPE_PERF_EVENT_HASHMAP for events in task
context.
hmm. why? don't see a use case yet.
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.
what you had also needs a map of one element.
also I don't think perf_events can be 'detached'. User space always will
perf_event_open one first and only then program will use it.
So passing FD from user space to the program is inevitable.
Other than storing FD into map the other alternative is to use ld_imm64
mechanism. Then the helper will only have one argument,
but then you'd need to extend 'used_maps' logic with 'used_fds'.
It's doable as well, but I think the use case of only one pmu counter
per cpu is artificial. You'll always have an array of events. One for
each cpu. So perf_event_array mechanism fits the best.
>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.
no, what I meant is to do sample code as tracex[1-5]*
where there is distinct kernel and user space parts. Both in C.
At this stage perf patches are way too early.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
