Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events

[Thomas Gleixner <tglx@linutronix.de>]

Vincent,

On Wed, 2 Mar 2011, Vincent Guittot wrote:
> On 2 March 2011 11:08, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Mon, 28 Feb 2011, Vincent Guittot wrote:
> >> The goal is to monitor the cpu hotplug activity and duration. I want
> >> to detect 2 kind of cpu_down/cpu_up call, ones which succeed to
> >> unplug/plug a core and ones which don't. But I'm not sure that we need
> >> to sort the failed calls into to the trace. We trace them because too
> >> much fails could point out a bug or a wrong use of cpu hotplug.
> >
> > This does not make sense at all. You want to see the failures, then
> > recording the error code makes even more sense. Your way of decoding
> > the error case by checking whether the next trace entry is there or
> > missing is just sloppy.
> >
> 
> The 1st goal was to focus on profiling and to make trace events as
> simple as possible but I agree that having all information is a better
> option. We can add a parameter in the trace which gets the return code
> or some test result like the value of cpu_hotplug_disabled.

That's neither a question of focus nor of better options.

The main point is correctness and usefulness. When we add new
facilities or infrastructure we want to make sure that they are
general useful and correct for all possible use cases we can imagine
at that point in time.

So yes, I understand your reasoning and your focus on your primary
interest, but I also want you to understand that this kind of review
has a very practical background (i.e. maintainability) and is not just
the annoying bullying people around conducted by grumpy old men.
 
Thanks,

	tglx