)]}' { "log": [ { "commit": "231375cc5cc3549bb413f94a164bdcbd5f9ce943", "tree": "03ff935268f5c551da14704d14667e6951a5b25f", "parents": [ "f2461fc82a083dd60062e05e704c5fcc1c658ba1" ], "author": { "name": "Mathieu Desnoyers", "email": "mathieu.desnoyers@polymtl.ca", "time": "Fri Oct 03 15:01:33 2008 -0400" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Tue Oct 14 10:39:31 2008 +0200" }, "message": "tracepoints: synchronize unregister static inline\n\nTurn tracepoint synchronize unregister into a static inline. There is no\nreason to keep it as a macro over a static inline.\n\nSigned-off-by: Mathieu Desnoyers \u003cmathieu.desnoyers@polymtl.ca\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "f2461fc82a083dd60062e05e704c5fcc1c658ba1", "tree": "1b5e13fd4895351d26e9bd4a404c40c8d8381a09", "parents": [ "8b27386a9ce9c7f0f8702cff7565a46802ad57d1" ], "author": { "name": "Mathieu Desnoyers", "email": "mathieu.desnoyers@polymtl.ca", "time": "Mon Oct 06 10:33:00 2008 -0400" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Tue Oct 14 10:39:30 2008 +0200" }, "message": "tracepoints: tracepoint_synchronize_unregister()\n\nCreate tracepoint_synchronize_unregister() which must be called before the end\nof exit() to make sure every probe callers have exited the non preemptible\nsection and thus are not executing the probe code anymore.\n\nSigned-off-by: Mathieu Desnoyers \u003cmathieu.desnoyers@polymtl.ca\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "97e1c18e8d17bd87e1e383b2e9d9fc740332c8e2", "tree": "5c6bfce8bacf04c2993a0029788a1370a483afa6", "parents": [ "e7f2f9918c0e97aa98ba147ca387e2c7238f0711" ], "author": { "name": "Mathieu Desnoyers", "email": "mathieu.desnoyers@polymtl.ca", "time": "Fri Jul 18 12:16:16 2008 -0400" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Tue Oct 14 10:28:28 2008 +0200" }, "message": "tracing: Kernel Tracepoints\n\nImplementation of kernel tracepoints. Inspired from the Linux Kernel\nMarkers. Allows complete typing verification by declaring both tracing\nstatement inline functions and probe registration/unregistration static\ninline functions within the same macro \"DEFINE_TRACE\". No format string\nis required. See the tracepoint Documentation and Samples patches for\nusage examples.\n\nTaken from the documentation patch :\n\n\"A tracepoint placed in code provides a hook to call a function (probe)\nthat you can provide at runtime. A tracepoint can be \"on\" (a probe is\nconnected to it) or \"off\" (no probe is attached). When a tracepoint is\n\"off\" it has no effect, except for adding a tiny time penalty (checking\na condition for a branch) and space penalty (adding a few bytes for the\nfunction call at the end of the instrumented function and adds a data\nstructure in a separate section). When a tracepoint is \"on\", the\nfunction you provide is called each time the tracepoint is executed, in\nthe execution context of the caller. When the function provided ends its\nexecution, it returns to the caller (continuing from the tracepoint\nsite).\n\nYou can put tracepoints at important locations in the code. They are\nlightweight hooks that can pass an arbitrary number of parameters, which\nprototypes are described in a tracepoint declaration placed in a header\nfile.\"\n\nAddition and removal of tracepoints is synchronized by RCU using the\nscheduler (and preempt_disable) as guarantees to find a quiescent state\n(this is really RCU \"classic\"). The update side uses rcu_barrier_sched()\nwith call_rcu_sched() and the read/execute side uses\n\"preempt_disable()/preempt_enable()\".\n\nWe make sure the previous array containing probes, which has been\nscheduled for deletion by the rcu callback, is indeed freed before we\nproceed to the next update. It therefore limits the rate of modification\nof a single tracepoint to one update per RCU period. The objective here\nis to permit fast batch add/removal of probes on _different_\ntracepoints.\n\nChangelog :\n- Use #name \":\" #proto as string to identify the tracepoint in the\n tracepoint table. This will make sure not type mismatch happens due to\n connexion of a probe with the wrong type to a tracepoint declared with\n the same name in a different header.\n- Add tracepoint_entry_free_old.\n- Change __TO_TRACE to get rid of the \u0027i\u0027 iterator.\n\nMasami Hiramatsu \u003cmhiramat@redhat.com\u003e :\nTested on x86-64.\n\nPerformance impact of a tracepoint : same as markers, except that it\nadds about 70 bytes of instructions in an unlikely branch of each\ninstrumented function (the for loop, the stack setup and the function\ncall). It currently adds a memory read, a test and a conditional branch\nat the instrumentation site (in the hot path). Immediate values will\neventually change this into a load immediate, test and branch, which\nremoves the memory read which will make the i-cache impact smaller\n(changing the memory read for a load immediate removes 3-4 bytes per\nsite on x86_32 (depending on mov prefixes), or 7-8 bytes on x86_64, it\nalso saves the d-cache hit).\n\nAbout the performance impact of tracepoints (which is comparable to\nmarkers), even without immediate values optimizations, tests done by\nHideo Aoki on ia64 show no regression. His test case was using hackbench\non a kernel where scheduler instrumentation (about 5 events in code\nscheduler code) was added.\n\nQuoting Hideo Aoki about Markers :\n\nI evaluated overhead of kernel marker using linux-2.6-sched-fixes git\ntree, which includes several markers for LTTng, using an ia64 server.\n\nWhile the immediate trace mark feature isn\u0027t implemented on ia64, there\nis no major performance regression. So, I think that we don\u0027t have any\nissues to propose merging marker point patches into Linus\u0027s tree from\nthe viewpoint of performance impact.\n\nI prepared two kernels to evaluate. The first one was compiled without\nCONFIG_MARKERS. The second one was enabled CONFIG_MARKERS.\n\nI downloaded the original hackbench from the following URL:\nhttp://devresources.linux-foundation.org/craiger/hackbench/src/hackbench.c\n\nI ran hackbench 5 times in each condition and calculated the average and\ndifference between the kernels.\n\n The parameter of hackbench: every 50 from 50 to 800\n The number of CPUs of the server: 2, 4, and 8\n\nBelow is the results. As you can see, major performance regression\nwasn\u0027t found in any case. Even if number of processes increases,\ndifferences between marker-enabled kernel and marker- disabled kernel\ndoesn\u0027t increase. Moreover, if number of CPUs increases, the differences\ndoesn\u0027t increase either.\n\nCuriously, marker-enabled kernel is better than marker-disabled kernel\nin more than half cases, although I guess it comes from the difference\nof memory access pattern.\n\n* 2 CPUs\n\nNumber of | without | with | diff | diff |\nprocesses | Marker [Sec] | Marker [Sec] | [Sec] | [%] |\n--------------------------------------------------------------\n 50 | 4.811 | 4.872 | +0.061 | +1.27 |\n 100 | 9.854 | 10.309 | +0.454 | +4.61 |\n 150 | 15.602 | 15.040 | -0.562 | -3.6 |\n 200 | 20.489 | 20.380 | -0.109 | -0.53 |\n 250 | 25.798 | 25.652 | -0.146 | -0.56 |\n 300 | 31.260 | 30.797 | -0.463 | -1.48 |\n 350 | 36.121 | 35.770 | -0.351 | -0.97 |\n 400 | 42.288 | 42.102 | -0.186 | -0.44 |\n 450 | 47.778 | 47.253 | -0.526 | -1.1 |\n 500 | 51.953 | 52.278 | +0.325 | +0.63 |\n 550 | 58.401 | 57.700 | -0.701 | -1.2 |\n 600 | 63.334 | 63.222 | -0.112 | -0.18 |\n 650 | 68.816 | 68.511 | -0.306 | -0.44 |\n 700 | 74.667 | 74.088 | -0.579 | -0.78 |\n 750 | 78.612 | 79.582 | +0.970 | +1.23 |\n 800 | 85.431 | 85.263 | -0.168 | -0.2 |\n--------------------------------------------------------------\n\n* 4 CPUs\n\nNumber of | without | with | diff | diff |\nprocesses | Marker [Sec] | Marker [Sec] | [Sec] | [%] |\n--------------------------------------------------------------\n 50 | 2.586 | 2.584 | -0.003 | -0.1 |\n 100 | 5.254 | 5.283 | +0.030 | +0.56 |\n 150 | 8.012 | 8.074 | +0.061 | +0.76 |\n 200 | 11.172 | 11.000 | -0.172 | -1.54 |\n 250 | 13.917 | 14.036 | +0.119 | +0.86 |\n 300 | 16.905 | 16.543 | -0.362 | -2.14 |\n 350 | 19.901 | 20.036 | +0.135 | +0.68 |\n 400 | 22.908 | 23.094 | +0.186 | +0.81 |\n 450 | 26.273 | 26.101 | -0.172 | -0.66 |\n 500 | 29.554 | 29.092 | -0.461 | -1.56 |\n 550 | 32.377 | 32.274 | -0.103 | -0.32 |\n 600 | 35.855 | 35.322 | -0.533 | -1.49 |\n 650 | 39.192 | 38.388 | -0.804 | -2.05 |\n 700 | 41.744 | 41.719 | -0.025 | -0.06 |\n 750 | 45.016 | 44.496 | -0.520 | -1.16 |\n 800 | 48.212 | 47.603 | -0.609 | -1.26 |\n--------------------------------------------------------------\n\n* 8 CPUs\n\nNumber of | without | with | diff | diff |\nprocesses | Marker [Sec] | Marker [Sec] | [Sec] | [%] |\n--------------------------------------------------------------\n 50 | 2.094 | 2.072 | -0.022 | -1.07 |\n 100 | 4.162 | 4.273 | +0.111 | +2.66 |\n 150 | 6.485 | 6.540 | +0.055 | +0.84 |\n 200 | 8.556 | 8.478 | -0.078 | -0.91 |\n 250 | 10.458 | 10.258 | -0.200 | -1.91 |\n 300 | 12.425 | 12.750 | +0.325 | +2.62 |\n 350 | 14.807 | 14.839 | +0.032 | +0.22 |\n 400 | 16.801 | 16.959 | +0.158 | +0.94 |\n 450 | 19.478 | 19.009 | -0.470 | -2.41 |\n 500 | 21.296 | 21.504 | +0.208 | +0.98 |\n 550 | 23.842 | 23.979 | +0.137 | +0.57 |\n 600 | 26.309 | 26.111 | -0.198 | -0.75 |\n 650 | 28.705 | 28.446 | -0.259 | -0.9 |\n 700 | 31.233 | 31.394 | +0.161 | +0.52 |\n 750 | 34.064 | 33.720 | -0.344 | -1.01 |\n 800 | 36.320 | 36.114 | -0.206 | -0.57 |\n--------------------------------------------------------------\n\nSigned-off-by: Mathieu Desnoyers \u003cmathieu.desnoyers@polymtl.ca\u003e\nAcked-by: Masami Hiramatsu \u003cmhiramat@redhat.com\u003e\nAcked-by: \u0027Peter Zijlstra\u0027 \u003cpeterz@infradead.org\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" } ] }