Message-ID: <20070706210840.GP3492@stusta.de>
Date:	Fri, 6 Jul 2007 23:08:40 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	Bodo Eggert <7eggert@....de>, Andi Kleen <andi@...stfloor.org>,
	Alexey Dobriyan <adobriyan@...il.com>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 10/10] Scheduler profiling - Use immediate values

On Thu, Jul 05, 2007 at 11:46:44AM -0400, Mathieu Desnoyers wrote:
> * Bodo Eggert (7eggert@....de) wrote:
> > Andi Kleen <andi@...stfloor.org> wrote:
> > > Alexey Dobriyan <adobriyan@...il.com> writes:
> > >> On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
> > 
> > >> > Use immediate values with lower d-cache hit in optimized version as a
> > >> > condition for scheduler profiling call.
> > >> 
> > >> I think it's better to put profile.c under CONFIG_PROFILING as
> > >> _expected_, so CONFIG_PROFILING=n users won't get any overhead, immediate or
> > >> not. That's what I'm going to do after test-booting bunch of kernels.
> > > 
> > > No, it's better to handle this efficiently at runtime e.g. for
> > > distribution kernels. Mathieu's patch is good
> > 
> > IMO you should combine them. For distibutions, it may be good to include
> > profiling support unconditionally, but how many of the vanilla kernel users
> > are going to use profiling at all?
> 
> For CONFIG_PROFILING, I think of it more like a chicken and egg problem:
> as long as it won't be easy to enable when needed in distributions
> kernels, few profiling applications will use it. So if you ban it from
> distros kernel with a CONFIG option under the pretext that no profiling
> application use it, you run straight into a conceptual deadlock. :)
> 
> Another simliar example would be CONFIG_TIMER_STATS, used by powertop,
> which users will use to tune their laptops (I got 45 minutes more
> battery time on mine thanks to this wonderful tool). Compiling-in, but
> dynamically turning it on/off makes sense for a lot of kernel
> "profiling/stats extraction" mechanisms like those.
> 
> But I suspect they will be used by distros only when their presence when
> disabled will be unnoticeable or when a major portion of their users
> will yell loudly enough telling that they want this and this features,
> leaving the more specialized minority of distro users without these
> features that they need to fine-tune their applications or their kernel.

There's a surprisingly simple solution solving the problems you describe:

For userspace libraries, the common approach is to get them stripped and
have versions with all debugging symbols in some -dbg package. So if you 
want to debug an application using such a library, you simply install 
this -dbg package.

Just let distributions make the same for the kernel - add a -dbg flavour 
with many debugging options enabled. It might perhaps run 5% or 20% 
slower than the regular kernel, but you don't need profiling or powertop 
during normal operation - these are _debug_ tools.

This way, there's no runtime penalty and therefore no trickery
required for getting the overhead of _debug code_ lower.

> Mathieu

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
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