| |||||||||||||
On the value of static tracepointsOn the value of static tracepointsPosted Apr 28, 2009 18:06 UTC (Tue) by fuhchee (subscriber, #40059)Parent article: On the value of static tracepoints
> After literally years of work, the developers came up with a scheme
> involving run-time code patching that reduces the performance cost of an > inactive tracepoint to, for all practical purposes, zero.
Can someone point me to the code that applies code patching to tracepoints?
(Log in to post comments)
Code patching Posted Apr 28, 2009 18:33 UTC (Tue) by corbet (editor, #1) [Link] Sigh. I had figured that the immediate values/kernel marker stuff was being used here, but a closer look makes it clear that tracepoints do not use that infrastructure. Not sure why. Sorry for the confusion.
Code patching Posted Apr 28, 2009 19:21 UTC (Tue) by compudj (subscriber, #43335) [Link]
The Immediate Values are still waiting in the LTTng tree. Actually, I am waiting to see enough tracepoints in the mainline Linux kernel to justify the use of Immediate Values before I re-post them. Otherwise, I seem to be the only one convinced of their use, given the number of tracepoints present in the LTTng kernel tree.
Regarding Mainline, kmemtrace adds enough tracepoints to have a tiny, but measurable, impact on the localhost tbench workload (one would still have to figure out if it's really statistically significant by running more passes than I can given the time I have on my hands). Note that this workload is _very_ heavy on the number of tracepoint sites executed and sensitive to cache-line layout changes.
I won't fight to push them, but if there is sufficient willingness to have them merged, I will consider posting them as a "git pull" request.
Mathieu
|
|||||||||||||