aboutsummaryrefslogtreecommitdiff
path: root/lib/Kconfig
diff options
context:
space:
mode:
authorSteven Rostedt <srostedt@redhat.com>2008-11-10 21:46:01 -0500
committerSteven Rostedt <srostedt@redhat.com>2008-11-10 21:47:37 -0500
commit4143c5cb36331155a1823af8b3a8c761a59fed71 (patch)
tree14ba50cd2a0acb5f18d7c657f08eaa586827fe27 /lib/Kconfig
parentbf5e6519b85b3853f2d0bb4f17a4e2eaeffeb574 (diff)
ring-buffer: prevent infinite looping on time stamping
Impact: removal of unnecessary looping The lockless part of the ring buffer allows for reentry into the code from interrupts. A timestamp is taken, a test is preformed and if it detects that an interrupt occurred that did tracing, it tries again. The problem arises if the timestamp code itself causes a trace. The detection will detect this and loop again. The difference between this and an interrupt doing tracing, is that this will fail every time, and cause an infinite loop. Currently, we test if the loop happens 1000 times, and if so, it will produce a warning and disable the ring buffer. The problem with this approach is that it makes it difficult to perform some types of tracing (tracing the timestamp code itself). Each trace entry has a delta timestamp from the previous entry. If a trace entry is reserved but and interrupt occurs and traces before the previous entry is commited, the delta timestamp for that entry will be zero. This actually makes sense in terms of tracing, because the interrupt entry happened before the preempted entry was commited, so one may consider the two happening at the same time. The order is still preserved in the buffer. With this idea, instead of trying to get a new timestamp if an interrupt made it in between the timestamp and the test, the entry could simply make the delta zero and continue. This will prevent interrupts or tracers in the timer code from causing the above loop. Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Diffstat (limited to 'lib/Kconfig')
0 files changed, 0 insertions, 0 deletions