Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030853AbbDWTve (ORCPT ); Thu, 23 Apr 2015 15:51:34 -0400 Received: from www.linutronix.de ([62.245.132.108]:38832 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030527AbbDWTvc (ORCPT ); Thu, 23 Apr 2015 15:51:32 -0400 Date: Thu, 23 Apr 2015 21:51:47 +0200 (CEST) From: Thomas Gleixner To: Steven Rostedt cc: linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org, Ingo Molnar , Andrew Morton , Peter Zijlstra , Linus Torvalds , Carsten Emde , Daniel Wagner , Jon Masters , Clark Williams Subject: Re: [RFC][PATCH 0/4] tracing: Add new hwlat_detector tracer In-Reply-To: <20150423190825.714359844@goodmis.org> Message-ID: References: <20150423190825.714359844@goodmis.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1767 Lines: 39 On Thu, 23 Apr 2015, Steven Rostedt wrote: > This is the port of the hardware latency detector from the -rt patch > to mainline. Instead of keeping it as a device that had its own debugfs > filesystem infrastructure, it made more sense to make it into a tracer > like irqsoff and wakeup latency tracers currently are. > > With this patch set, a new tracer is enabled if CONFIG_HWLAT_TRACER is > enabled. Inside the available_tracers file will be hwlat_detector. > > # cd /sys/kernel/debug/tracing > # echo hwlat_detector > current_tracer > > will enable the hwlat_detector that will create per cpu kernel threads > (which cpus is defined by the tracing/hwlat_detector/cpumask, default > is just CPU 0). > > Like the other tracers (function, function_graph, preemptirqsoff, > and mmiotracer), the hwlat_detector can add a significant performance > penalty when enabled. As each of the threads created will go into a spin > checking the trace_local_clock (sched_clock) for any gaps of time > and will report them if they are greater than the threshold defined > by tracing/tracing_thresh (usecs, default 10). The spin is performed with > interrupts disabled and runs for "width" usecs in "window" usecs time. The That's fine, but this still lacks a detection of NMI disturbance. We've seen false positives reported over and over when stuff like the NMI watchdog or perf was enabled while running this. Aside of that isn't there a way to detect SMI crap with performance counters on recent hardware? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/