)]}' { "log": [ { "commit": "f66af459a931f25807e1df7915b2b66bb5978d82", "tree": "bb88917429fe1ea4f6d6e088ead040b25d205a86", "parents": [ "5209f08dc8e5f520ca81b87fa9a7142f58a109f4" ], "author": { "name": "Frederic Weisbecker", "email": "fweisbec@gmail.com", "time": "Wed Oct 22 19:14:55 2008 +0200" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Mon Oct 27 16:45:46 2008 +0100" }, "message": "tracepoint: check if the probe has been registered\n\nImpact: fix kernel crash that can trigger during tracing\n\nIf we try to remove a probe that has not been already registered,\nthe tracepoint_entry_remove_probe() function will dereference a NULL\npointer.\n\nCheck the probe before removing it to avoid crashes.\n\nSigned-off-by: Frederic Weisbecker \u003cfweisbec@gmail.com\u003e\nAcked-by: Mathieu Desnoyers \u003cmathieu.desnoyers@polymtl.ca\u003e\nAcked-by: Steven Rostedt \u003csrostedt@redhat.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "9a1e9693f534174945154197fec4ec92f168ce21", "tree": "d1477dc3492812c2f8a93afe37075857d4b1ce0f", "parents": [ "ca2db6cf30d6a45798b7a760d0c4f7735b16799d" ], "author": { "name": "Mathieu Desnoyers", "email": "mathieu.desnoyers@polymtl.ca", "time": "Tue Sep 30 01:51:12 2008 -0400" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Tue Oct 14 10:38:23 2008 +0200" }, "message": "tracepoints: fix reentrancy\n\nThe tracepoints had the same problem markers did have wrt reentrancy. Apply a\nsimilar fix using a rcu_barrier after each tracepoint mutex lock.\n\nSigned-off-by: Mathieu Desnoyers \u003cmathieu.desnoyers@polymtl.ca\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "ca2db6cf30d6a45798b7a760d0c4f7735b16799d", "tree": "5c1658ec172fdaa04ee018972eb96f0f2c409676", "parents": [ "d74185ed27651ad8d920b37d7851306ad01f7d6f" ], "author": { "name": "Mathieu Desnoyers", "email": "mathieu.desnoyers@polymtl.ca", "time": "Tue Sep 30 01:49:39 2008 -0400" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Tue Oct 14 10:38:21 2008 +0200" }, "message": "tracepoints: use rcu sched\n\nMake tracepoints use rcu sched. (cleanup)\n\nSigned-off-by: Mathieu Desnoyers \u003cmathieu.desnoyers@polymtl.ca\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "9795302acf2817d0842e56d23df6008e43df0970", "tree": "de2219d52413770567e656b8e6e6b4da7fbf6fca", "parents": [ "611b1597680dd4a57896bcca1af0484be463c55e" ], "author": { "name": "Mathieu Desnoyers", "email": "mathieu.desnoyers@polymtl.ca", "time": "Thu Jul 24 16:37:23 2008 -0400" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Tue Oct 14 10:34:07 2008 +0200" }, "message": "tracepoints: use TABLE_SIZE macro\n\nSteven Rostedt suggested:\n\n| Wouldn\u0027t it look nicer to have: (TRACEPOINT_TABLE_SIZE - 1) ?\n\nSigned-off-by: Mathieu Desnoyers \u003cmathieu.desnoyers@polymtl.ca\u003e\nCc: Steven Rostedt \u003crostedt@goodmis.org\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" } ] }