<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br data-mce-bogus="1"></div><span id="zwchr" data-marker="__DIVIDER__">----- On Jul 6, 2021, at 10:37 PM, lttng-dev <lttng-dev@lists.lttng.org> wrote:<br></span><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div class="__aliyun_email_body_block"><div><span style="font-family:'tahoma' , 'arial' , 'stheiti' , 'simsun';font-size:14px;color:#000000">Hi, </span></div><div><span style="font-family:'tahoma' , 'arial' , 'stheiti' , 'simsun';font-size:14px;color:#000000"> I know lttng-ust tracepoint process uses per cpu lockless ringbuffer algorithm for high performance so that it relies on getcpu() to return the cpu number on which the app is running.</span></div><div><span style="font-family:'tahoma' , 'arial' , 'stheiti' , 'simsun';font-size:14px;color:#000000"> Unfortunately, I am working on arm that linux kernel does not support vdso getcpu() implemention and one getcpu() will take 200ns!!!</span></div><div><span style="font-family:'tahoma' , 'arial' , 'stheiti' , 'simsun';font-size:14px;color:#000000"> My question is :</span></div><div><span style="font-family:'tahoma' , 'arial' , 'stheiti' , 'simsun';font-size:14px;color:#000000"> 1. do you have any advice for that?</span></div></div></blockquote><div><br></div><div>You might want to try wiring up the "rseq" system call in user-space to provide an accurate cpu_id<br data-mce-bogus="1"></div><div>field in a __rseq_abi TLS variable. It is always kept up to date by the kernel. The rseq system call<br data-mce-bogus="1"></div><div>is implemented on ARM. However the __rseq_abi TLS is a shared resource across libraries, and<br data-mce-bogus="1"></div><div>we have not agreed with glibc people on how exactly it must be shared within a process.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div class="__aliyun_email_body_block"><div><span style="font-family:'tahoma' , 'arial' , 'stheiti' , 'simsun';font-size:14px;color:#000000"> 2. If I implement a cache-version for getcpu()(just like getcpu() implemention before kernel 2.6.23 ), what will happen during tracing process? </span></div></div></blockquote><div>You'd have to give more details on how this "cache-version" works.</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div class="__aliyun_email_body_block"><div><span style="font-family:'tahoma' , 'arial' , 'stheiti' , 'simsun';font-size:14px;color:#000000"> Since use of the cache could speed getcpu() calls, at the cost that there was a very small chance that the returned cpu number would be out of date, I am not sure whether the "wrong" cpu number will result in the tracing app crashing?</span></div></div></blockquote><div><br></div><div>LTTng-UST always has to expect that it can be migrated at any point between getcpu and writes to<br data-mce-bogus="1"></div><div>per-cpu data. Therefore, it always relies on atomic operations when interacting with the ring buffer,<br data-mce-bogus="1"></div><div>and there is no expectation that it runs on the "right" CPU compared to the ring buffer data structure<br data-mce-bogus="1"></div><div>for consistency. Therefore, you won't experience crashes nor corruption even if the CPU number is</div><div>wrong once in a while, as long as it belongs to the "possible CPUs".<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>This behavior is selected by lttng's libringbuffer "RING_BUFFER_SYNC_GLOBAL" configuration<br data-mce-bogus="1"></div><div>option internally, as selected by lttng-ust.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Note that the kernel tracer instead selects "RING_BUFFER_SYNC_PER_CPU", which is faster, but<br data-mce-bogus="1"></div><div>requires that preemption (or migration) be disabled between the "smp_processor_id()" and writes to</div><div>the ring buffer per-cpu data structures.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Thanks,<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Mathieu<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div class="__aliyun_email_body_block"><div><span style="font-family:'tahoma' , 'arial' , 'stheiti' , 'simsun';font-size:14px;color:#000000"><br></span></div><div><span style="font-family:'tahoma' , 'arial' , 'stheiti' , 'simsun';font-size:14px;color:#000000">Thanks</span></div><div><span style="font-family:'tahoma' , 'arial' , 'stheiti' , 'simsun';font-size:14px;color:#000000">zhenyu.ren</span></div></div><br>_______________________________________________<br>lttng-dev mailing list<br>lttng-dev@lists.lttng.org<br>https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev<br></blockquote></div><br><div data-marker="__SIG_POST__">-- <br></div><div>Mathieu Desnoyers<br>EfficiOS Inc.<br>http://www.efficios.com</div></div></body></html>