Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

Please Ingo, stop repeating false argument without taking in account people's
corrections :

* Ingo Molnar (mingo@xxxxxxx) wrote:
sorry, but i disagree. There _is_ a solution that is superior in every
aspect: kprobes + SystemTap. (or any other equivalent dynamic tracer)


I am sorry to have to repeat myself, but this is not true for heavy loads.

At this point you've been rather uncompromising [...]

yes, i'm rather uncompromising when i sense attempts to push inferior
concepts into the core kernel _when_ a better concept exists here and
today. Especially if the concept being pushed adds more than 350
tracepoints that expose something to user-space that amounts to a
complex external API, which tracepoints we have little chance of ever
getting rid of under a static tracing concept.

From an earlier email from Tim bird :

"I still think that this is off-topic for the patch posted. I think we
should debate the implementation of tracepoints/markers when someone posts a
patch for some. I think it's rather scurrilous to complain about
code NOT submitted. Ingo has even mis-characterized the not-submitted
instrumentation patch, by saying it has 350 tracepoints when it has no
such thing. I counted 58 for one architecture (with only 8 being
arch-specific)."

Mathieu

OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [announce] CFS-devel, performance improvements
    ... This needs a little perspective, as I couldn't clone the repository, all I had was this announcement, so using the patch descriptions now as defense is unfair by you. ... The most brilliant mathematician in the world would have nothing to contribute to the Linux scheduler if he couldn't describe, code, and comment his algorithm in detail so that others could grok at least the basic outline and be able to give useful commentary and suggestions. ... I did however get the impression that Ingo got something significantly useful out of your code despite the problems, but I still haven't had time to read through his and Peter's patches in detail to understand exactly what it was. ...
    (Linux-Kernel)
  • [patch] auto-qa Kconfig
    ... problem with the patch below. ... Please test lots of configs. ... Ingo seems to be saying that he has some kind of "automated" build ... (the CONFIG_BOOTPARAM stuff is there to easily randomize boot options - ...
    (Linux-Kernel)
  • Re: cpu2000(both float and int) 13% regression with 2.6.28-rc1
    ... I bisected down to below patch. ... Ingo, I will work with Yanmin and report our findings. ... Anyhow, while we look at this, probably this is the best point to add "noxsave" ... Introduce "noxsave" boot parameter which will disable the cpu's xsave/xrstor ...
    (Linux-Kernel)
  • Re: [v2.6.26] whats brewing in x86.git for v2.6.26
    ... Thank you very much for the review of this patch. ... > The reason we didn't do this at once is that the making of kmemcheck ... > Ingo, will you take this for some additional testing? ... reason for using early_param, but that reason cannot be discerned from ...
    (Linux-Kernel)
  • Re: 2.6.24-rc8-git1: Reported regressions from 2.6.23
    ... There are thirteen regressions for which we have patches but they aren't ... This patch is certainly different. ... And I think Ingo fixed it ... Fixed by commit 73946f9fc5be1433f1e182d11303188390ff242f, afaik. ...
    (Linux-Kernel)