Re: [PATCH RFC] perf kvm stat live: cache mmap()ed events

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Mon, Sep 15, 2014 at 04:57:34PM +0400, Alexander Yarygin escreveu:
> David Ahern <dsahern@gmail.com> writes:
> > On 9/12/14, 10:27 AM, Alexander Yarygin wrote:
> >> During mmap() process 'perf kvm stat live' gets a pointer to events and
> >> passes them to the session queue. Events are stored in shared memory and
> >> eventually they will be overwritten by the kernel. The problem is, that
> >> when events come too fast, old events can be overwritten before they
> >> have been processed that can lead to perf crash.
> >>
> >> To prevent that happening, we can copy upcoming events and pass a copy
> >> to the session queue. There is a safe place to copy event: before
> >> perf_evlist__mmap_consume() is executed. There are 3 places to free it:
> >> when event is processed, when it's lost and on exit, if it's turned out
> >> unprocessed.

> > Did you see what I proposed a year ago:
> > https://lkml.org/lkml/2013/9/6/388

> > The intent is to keep the copy generic and not local a command since
> > conceptually other live commands need the same.

> Yes, your patch works fine. But as far as I understand, right now only
> the 'perf kvm stat live' is infected: other 'live' tools were fixed by
> the patch "PERF: The tail position of the event buffer should only be modified
> after actually use that event." and since they don't use ordered queue
> they don't need a copying. That's why I came up with 'perf kvm stat
> live' specific approach. Maybe I missed something...
> 
> Anyhow, having >30K events is a quite usual situation on s390 and the
> 'perf kvm stat live' command hardly works there, so it would be good to
> have at least some working solution. Any ideas? :)

I don't have a problem solving this on some tool where the problem
happens and then, when some other tool hits the same problem, then one
looks at existing tools, figures out if some tool-specific solution can
be reused, moves it to common code, possibly improving it in the
process, and reuses it.

Sometimes trying to make it general from day one may lead to
overengineering :-)

With that said, David's patch looks clean and small enough, so if that
solves your problem, please let me know if I can apply it and your
Tested-by/Any-other-tags, ok?

- Arnaldo