Re: [patch 10/10] Scheduler profiling - Use immediate values

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

* 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.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68