From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752387AbcHLSNy (ORCPT ); Fri, 12 Aug 2016 14:13:54 -0400 Received: from mail-qk0-f180.google.com ([209.85.220.180]:36394 "EHLO mail-qk0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751512AbcHLSNx (ORCPT ); Fri, 12 Aug 2016 14:13:53 -0400 Subject: Re: [PATCH v2 0/4] tracing: Add Hardware Latency detector tracer To: Steven Rostedt , linux-kernel@vger.kernel.org References: <20160810135356.265780824@goodmis.org> Cc: Ingo Molnar , Andrew Morton , Clark Williams , Thomas Gleixner , Jon Masters , Daniel Wagner , Carsten Emde , Sebastian Andrzej Siewior , Peter Zijlstra From: Daniel Bristot de Oliveira Message-ID: <32d79850-115b-49e0-5d0c-03a08d5fb550@redhat.com> Date: Fri, 12 Aug 2016 15:13:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160810135356.265780824@goodmis.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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