Messages in this thread | | | Date | Sat, 27 Nov 2010 00:55:24 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [PATCH 2/5] perf events: Default to using event__process_lost |
| |
On Fri, 26 Nov 2010, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo <acme@redhat.com> > > Tool developers have to fill in a 'perf_event_ops' method table to > specify how to handle each event, so far the ones that were not > explicitely especified would get a stub that would just discard the > event. > > Change that so that tool developers can get the lost event details and > the total number of such events at the end of 'perf report -D' output.
That should be always displayed if the subcommand does not have it's own lost event handling. I stared long enough into the wrong place, just because the stupid thing just was silent about it. And with this patch it's still silent for the normal use case.
We really want to tell the user when something went wrong. Users do not run perf report -D when the tool shows fancy events, why should they? Just because they know that the tool is hiding problems? If that's the case then the trust into perf tools is about 0.
Darn, being silent about a known problem is the most stupid error handling ever.
That's what I added at the end of perf_session__process_events()
+ if (self->hists.stats.total_lost) + fprintf(stderr, "Lost events. Check IO/CPU overload!\n");
It's hacky, but it does the job and tells me clearly that the trace is only halfways useful.
There are only two files, which implement their own lost handling: builtin-inject.c and builtin-script.c
So everything else looks at incomplete data and let's the user wonder about the resulting crap in the output.
Thanks,
tglx
| |