On Thu, 11 Oct 2018 16:02:07 +0200, Daniel Borkmann wrote:
> Clean up and improve bpf_perf_event_read_simple() ring walk a bit
> to use similar tail update scheme as in perf and bcc allowing the
> kernel to make forward progress not only after full timely walk.
The extra memory barriers won't impact performance? If I read the code
correctly we now have:
while (bla) {
head = HEAD
rmb()
...
mb()
TAIL = tail
}
Would it make sense to try to piggy back on the mb() for head re-read
at least? Perhaps that's a non-issue, just wondering.
> Also few other improvements to use realloc() instead of free() and
> malloc() combination and for the callback use proper perf_event_header
> instead of void pointer, so that real applications can use container_of()
> macro with proper type checking.
FWIW the free() + malloc() was to avoid the the needless copy of the
previous event realloc() may do. It makes sense to use realloc()
especially if you want to put extra info in front of the buffer, just
sayin' it wasn't a complete braino ;)
> Signed-off-by: Daniel Borkmann <dan...@iogearbox.net>
