Re: [PATCH 2/5] perf events: Default to using event__process_lost

[Thomas Gleixner]

On Fri, 26 Nov 2010, Arnaldo Carvalho de Melo wrote:

> From: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
> 
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/