Messages in this thread | | | Subject | Re: [PATCH v2 0/4] tracing: Add Hardware Latency detector tracer | From | Daniel Bristot de Oliveira <> | Date | Fri, 12 Aug 2016 15:13:46 -0300 |
| |
On 08/10/2016 10:53 AM, Steven Rostedt wrote: > This adds the PREEMPT_RT hwlat detector as a Linux tracer in mainline. > In the PREEMPT_RT patch set, it is a separate entity that is controlled > by the debugfs file system. I found that it is better suited as a > latency tracer in the tracing directory, as it follows pretty much the > same paradigm as the other latency tracers that already exist. All > I had to add was a hwlat_detector directory that contained a window > and width for the period and duration respectively of the test. But > the samples would just write to the tracing ring buffer and the max > latency would be stored in tracing_max_latency, and the threshold can > be set by the existing tracing_threshold. The last patch also adds a > new feature that would have the kthread migrate after each period to > another CPU specified by tracing_cpumask.
Hi!
I tested this patchset in a system which I can cause SMIs. The results are consistent with the latency I see when I run cyclictest in this box and cause SMIs on it. The tracer will be more accurate, as expected. So:
Tested-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Regarding SMI count, when I added SMI count support to cyclictest I based hardware support check on turbostat's implementation, at
tools/power/x86/turbostat/turbostat.c:probe_nhm_msrs()
It is for user-space, but I think it is a good starting point... Just thinking aloud.
-- Daniel
| |