linux-kernel - Re: [PATCH v2 0/4] tracing: Add Hardware Latency detector tracer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <32d79850-115b-49e0-5d0c-03a08d5fb550@redhat.com>
Date:	Fri, 12 Aug 2016 15:13:46 -0300
From:	Daniel Bristot de Oliveira <bristot@...hat.com>
To:	Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org
Cc:	Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Clark Williams <williams@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jon Masters <jcm@...hat.com>, Daniel Wagner <wagi@...om.org>,
	Carsten Emde <C.Emde@...dl.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v2 0/4] tracing: Add Hardware Latency detector tracer

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@...hat.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