)]}' { "log": [ { "commit": "629928041c53771f9902753d50fef6b35f36d33d", "tree": "e960bf1f0311a2d00eadebfc1304662a149e32fe", "parents": [ "fd99498989f3b3feeab89dcadf537138ba136d24" ], "author": { "name": "Steven Rostedt", "email": "srostedt@redhat.com", "time": "Sat Feb 28 02:47:59 2009 -0500" }, "committer": { "name": "Steven Rostedt", "email": "srostedt@redhat.com", "time": "Sat Feb 28 04:04:13 2009 -0500" }, "message": "tracing: create the C style tracing for the sched subsystem\n\nThis patch utilizes the TRACE_EVENT_FORMAT macro to enable the C style\nfaster tracing for the sched subsystem trace points.\n\nSigned-off-by: Steven Rostedt \u003csrostedt@redhat.com\u003e\n" }, { "commit": "3cdfdf91fcc77cfc82592e2b5c2ab35abe819c41", "tree": "176e2dbbf4e8c6ab59d0243f501338d104d7a31f", "parents": [ "eef62a6826b8ab530cefff5aa55c1661a209c803" ], "author": { "name": "Steven Rostedt", "email": "srostedt@redhat.com", "time": "Wed Feb 25 15:54:30 2009 -0500" }, "committer": { "name": "Steven Rostedt", "email": "srostedt@redhat.com", "time": "Wed Feb 25 21:44:26 2009 -0500" }, "message": "tracing: wrap arguments with PARAMS\n\nPeter Zijlstra warned that TPPROTO and TPARGS might become something\nother than a simple copy of itself. To prevent this from having\nside effects in the TRACE_FORMAT macro in tracepoint.h, we add a\nPARAMS() macro to be defined as just a wrapper.\n\nReported-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nSigned-off-by: Steven Rostedt \u003csrostedt@redhat.com\u003e\n" }, { "commit": "eef62a6826b8ab530cefff5aa55c1661a209c803", "tree": "f24c7f08b9a6ed443c09f26509cf2cf26fb8a19c", "parents": [ "d7350c3f45694104e820041969c8185c5f99e57c" ], "author": { "name": "Steven Rostedt", "email": "srostedt@redhat.com", "time": "Wed Feb 25 15:49:52 2009 -0500" }, "committer": { "name": "Steven Rostedt", "email": "srostedt@redhat.com", "time": "Wed Feb 25 21:44:22 2009 -0500" }, "message": "tracing: rename DEFINE_TRACE_FMT to just TRACE_FORMAT\n\nThere\u0027s been a bit confusion to whether DEFINE/DECLARE_TRACE_FMT should\nbe a DEFINE or a DECLARE. Ingo Molnar suggested simply calling it\nTRACE_FORMAT.\n\nReported-by: Ingo Molnar \u003cmingo@elte.hu\u003e\nSigned-off-by: Steven Rostedt \u003csrostedt@redhat.com\u003e\n" }, { "commit": "7c37730cd31ddb2d3a1da142af9b18c29b8c433b", "tree": "60e2d4a1b53dba29824b967345bc43814853b8a4", "parents": [ "c478f8786973d6d7552c652ddad3f6fd86b5af28" ], "author": { "name": "Steven Rostedt", "email": "srostedt@redhat.com", "time": "Tue Feb 24 12:07:53 2009 -0500" }, "committer": { "name": "Steven Rostedt", "email": "srostedt@redhat.com", "time": "Tue Feb 24 21:53:32 2009 -0500" }, "message": "tracing: add DEFINE_TRACE_FMT to tracepoint.h\n\nThis patch creates a DEFINE_TRACE_FMT to map to DECLARE_TRACE.\nThis allows for the developers to place format strings and\nargs in with their tracepoint declaration. A tracer may now\noverride the DEFINE_TRACE_FMT macro and use it to record\na default format.\n\nSigned-off-by: Steven Rostedt \u003csrostedt@redhat.com\u003e\n" }, { "commit": "7e066fb870fcd1025ec3ba7bbde5d541094f4ce1", "tree": "52acda06de25c029b9834110d7bf6b4abc50353b", "parents": [ "32f85742778dfc2c74975cf0b9f5bdb13470cb32" ], "author": { "name": "Mathieu Desnoyers", "email": "mathieu.desnoyers@polymtl.ca", "time": "Fri Nov 14 17:47:47 2008 -0500" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Sun Nov 16 09:01:36 2008 +0100" }, "message": "tracepoints: add DECLARE_TRACE() and DEFINE_TRACE()\n\nImpact: API *CHANGE*. Must update all tracepoint users.\n\nAdd DEFINE_TRACE() to tracepoints to let them declare the tracepoint\nstructure in a single spot for all the kernel. It helps reducing memory\nconsumption, especially when declaring a lot of tracepoints, e.g. for\nkmalloc tracing.\n\n*API CHANGE WARNING*: now, DECLARE_TRACE() must be used in headers for\ntracepoint declarations rather than DEFINE_TRACE(). This is the sane way\nto do it. The name previously used was misleading.\n\nUpdates scheduler instrumentation to follow this API change.\n\nSigned-off-by: Mathieu Desnoyers \u003cmathieu.desnoyers@polymtl.ca\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "5f382671def7cb9c0f4b75d586dc5f60dca5e1c3", "tree": "ee90d469b24a893c8ec777775a43d41cdfb6f76f", "parents": [ "c420970ef476d7d68df119711700666224001f43" ], "author": { "name": "Mathieu Desnoyers", "email": "mathieu.desnoyers@polymtl.ca", "time": "Fri Nov 14 17:47:45 2008 -0500" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Sun Nov 16 09:01:34 2008 +0100" }, "message": "tracepoints: do not put arguments in name\n\nImpact: cleanup\n\nThat\u0027s overkill, takes space. We have a global tracepoint registery in\nheader files anyway.\n\nSigned-off-by: Mathieu Desnoyers \u003cmathieu.desnoyers@polymtl.ca\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "c420970ef476d7d68df119711700666224001f43", "tree": "c10ebb11a03199f99d779472037bd49129b43abb", "parents": [ "da7b3eab167091693ad215ad7692f7d0d24d1356" ], "author": { "name": "Mathieu Desnoyers", "email": "mathieu.desnoyers@polymtl.ca", "time": "Fri Nov 14 17:47:44 2008 -0500" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Sun Nov 16 09:01:33 2008 +0100" }, "message": "tracepoints: use unregister return value\n\nImpact: bugfix.\n\nUnregistering a tracepoint can fail. Return the error value.\n\nSigned-off-by: Mathieu Desnoyers \u003cmathieu.desnoyers@polymtl.ca\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "da7b3eab167091693ad215ad7692f7d0d24d1356", "tree": "a879fc523166fdaf196fe128e11246996eda0480", "parents": [ "de0baf9ad661ac630a45a50ea1717cc4f4b33ace" ], "author": { "name": "Mathieu Desnoyers", "email": "mathieu.desnoyers@polymtl.ca", "time": "Fri Nov 14 17:47:43 2008 -0500" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Sun Nov 16 09:01:32 2008 +0100" }, "message": "tracepoints: use rcu_*_sched_notrace\n\nMake sure tracepoints can be called within ftrace callbacks.\n\nSigned-off-by: Mathieu Desnoyers \u003cmathieu.desnoyers@polymtl.ca\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "commit": "127cafbb276266b1b8da967bfe25a062ab1d42ab", "tree": "8f7183fa6f9a68b2bd3b3734da3575e4eff46a1d", "parents": [ "19dba33c43a2f0f2aa727ae075ec3b11330775ef" ], "author": { "name": "Lai Jiangshan", "email": "laijs@cn.fujitsu.com", "time": "Tue Oct 28 10:51:53 2008 +0800" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Mon Nov 03 10:28:52 2008 +0100" }, "message": "tracepoint: introduce *_noupdate APIs.\n\nImpact: add new tracepoint APIs to allow the batched registration of probes\n\nnew APIs separate tracepoint_probe_register(),\ntracepoint_probe_unregister() into 2 steps. The first step of them\nis just update tracepoint_entry, not connect or disconnect.\n\nthis patch introduces tracepoint_probe_update_all() for update all.\n\nthese APIs are very useful for registering lots of probes\nbut just updating once. Another very important thing is that\n*_noupdate APIs do not require module_mutex.\n\nSigned-off-by: Lai Jiangshan \u003claijs@cn.fujitsu.com\u003e\nAcked-by: Mathieu Desnoyers \u003cmathieu.desnoyers@polymtl.ca\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n" }, { "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" } ] }