kernel defconfig, debugging, preemption, and very noticeable speedups/ debugging

Werner Almesberger werner at openmoko.org
Mon Jan 11 10:51:31 CET 2010


Gennady Kupava wrote:
> i went out of that discussions absolutely frustrated.

I saw that little flame fest a bit later. I noticed that you seemed
quite distressed, but I don't quite understand why.

Everybody agrees that you discovered something important. Everbody
also agrees that the current debugging options need changing. The
only thing where there's disagreement is about what degree of
changing your research so far justifies.

The previous assumption was that debug options are good to have and
their cost is negligible. So we used plenty of them.

You've shown that this is incorrect. However, the conclusion drawn
from this was is that all debug options are evil and they all must
be avoided.

The data you provided doesn't support such a radical conclusion.

Maybe it's clearer if I express this mathematically. D be a set of
debug options, D_{OM} be the set of of debug options the Openmoko
kernels used so far, cost(x) be the cost of debug option x where x
can be a single option used alone or a set of debug options.
Finally, \epsilon be the (non-zero) cost we would still consider
negligible.

The previous assumption was   cost(D_{OM}) < \epsilon
What you've shown is          cost(D_{OM}) \gg cost(\emptyset)
implying                      cost(D_{OM}) \gg \epsilon
Furthermore, you stated that  \sum{d in D} cost(d) \le cost{D}
The conclusion drawn is       \forall d \in D: cost(d) > \epsilon
and therefore		      \nexists D \ne \emptyset: cost(D) < \epsilon

I think everybody agrees except for the last two points. And I hope
you can agree that these last points don't follow from the rest :)

It would help to clarify the issue if you could post the results of
\forall d \in D_{OM}: cost(d)
or, if you prefer to emphasize the superlinear increase of cost when
combining options, a sequence of
cost(d_0), cost({d_0, d_1}), cost({d_0, d_1, d_2}), ...

Let's replace voodoo with science, not old voodoo with new voodoo :-)

Thanks,
- Werner



More information about the openmoko-kernel mailing list