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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1103022201440.2701@localhost6.localdomain6>
Date:	Wed, 2 Mar 2011 22:12:01 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Vincent Guittot <vincent.guittot@...aro.org>
cc:	linux-kernel@...r.kernel.org, linux-hotplug@...r.kernel.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>, amit.kucheria@...aro.org,
	Rusty Russell <rusty@...tcorp.com.au>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events

Vincent,

On Wed, 2 Mar 2011, Vincent Guittot wrote:
> On 2 March 2011 11:08, Thomas Gleixner <tglx@...utronix.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/