lkml.org 
[lkml]   [2007]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 10/10] Scheduler profiling - Use immediate values
On Thu, Jul 05, 2007 at 11:46:44AM -0400, Mathieu Desnoyers wrote:
> * Bodo Eggert (7eggert@gmx.de) wrote:
> > Andi Kleen <andi@firstfloor.org> wrote:
> > > Alexey Dobriyan <adobriyan@gmail.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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-07-06 23:11    [W:0.040 / U:0.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site