Date:	Sat, 7 Jul 2007 19:20:12 +0200
From:	Willy Tarreau <w@....eu>
To:	Adrian Bunk <bunk@...sta.de>
Cc:	"Frank Ch. Eigler" <fche@...hat.com>,
	Dave Jones <davej@...hat.com>,
	Chuck Ebbert <cebbert@...hat.com>,
	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Alexey Dobriyan <adobriyan@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 10/10] Scheduler profiling - Use immediate values

On Sat, Jul 07, 2007 at 07:01:57PM +0200, Adrian Bunk wrote:
> On Sat, Jul 07, 2007 at 11:45:20AM -0400, Frank Ch. Eigler wrote:
> > Adrian Bunk <bunk@...sta.de> writes:
> > 
> > > [...]
> > > profiling = debugging of performance problems
> > 
> > Indeed.
> > 
> > > My words were perhaps a bit sloppy, but profiling isn't part of
> > > normal operation and if people use a separate kernel for such
> > > purposes we don't need infrastructure for reducing performance
> > > penalties of enabled debug options.
> > 
> > Things are not so simple.  One might not know that one has a
> > performance problem until one tries some analysis tools.  Rebooting
> > into different kernels just to investigate does not work generally:
> > the erroneous phenomenon may have been short lived; the debug kernel,
> > being "only" for debugging, may not be well tested => sufficiently
> > trustworthy.
> 
> I'm not getting this:
> 
> You'll only start looking into an analysis tool if you have a 
> performance problem, IOW if you are not satisfied with the performance.
> 
> And the debug code will not have been tested on this machine no matter 
> whether it's enabled through a compile option or at runtime.

At least all the rest of the code will be untouched and you will not have
to reboot the machine. If you reboot to another kernel, nothing ensures
that you will have the same code sequences (in fact, gcc will reorder
some parts of code such as loops just because of an additional 'if').
So you know that the non-debug code you run will remain untouched. *This*
is important, because the debug code is not there to debug itself, but
to debug the rest.

> > Your question asking for an actual performance impact of dormant hooks
> > is OTOH entirely legitimate.  It clearly depends on the placement of
> > those hooks and thus their encounter rate, more so than their
> > underlying technology (markers with whatever optimizations).  If the
> > cost is small enough, you will likely find that people will be willing
> > to pay a small fraction of average performance, in order to eke out
> > large gains when finding occasional e.g. algorithmic bugs.
> 
> If you might be able to get a big part of tracing and other debug code 
> enabled with a performance penalty of a few percent of _kernel_ 
> performance, then you might get much debugging aid without any effective 
> impact on application performance.

it largely depends on the application. Applications which require a lot
of system calls will be more sensible to kernel debugging. Common sense
also implies that such applications will be the ones for which kernel
debugging will be relevant.

> You always have to decide between some debug code and some small bit of 
> performance. There's a reason why options to disable things like BUG() 
> or printk() are in the kernel config menus hidden behind CONFIG_EMBEDDED
> although they obviously have some performance impact.

It is not for the CPU performance they can be disabled, but for the code
size which is a real problem on embedded system. While you often have
mem/cpu_mhz ratios around 1GB/1GHz on servers and desktops, you more often
have ratios like 16MB/500MHz which is 1:32 of the former. That's why you
optimize for size at the expense of speed on such systems.

> 
> > - FChE
> 
> cu
> Adrian

Regards,
Willy

-
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/

Powered by blists - more mailing lists