Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758289AbbDWUJa (ORCPT ); Thu, 23 Apr 2015 16:09:30 -0400 Received: from smtprelay0048.hostedemail.com ([216.40.44.48]:52757 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1758106AbbDWUJ3 (ORCPT ); Thu, 23 Apr 2015 16:09:29 -0400 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::::::::::::::::,RULES_HIT:41:355:379:541:599:800:960:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1777:1792:1981:2194:2199:2393:2553:2559:2562:2890:3138:3139:3140:3141:3142:3353:3622:3865:3866:3867:3868:3870:3871:3872:3874:4042:4250:4559:5007:6261:7875:9038:10004:10400:10450:10455:10848:10967:11232:11658:11914:12296:12517:12519:12740:13069:13311:13357:14096:14097:19904:19999:21080,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0 X-HE-Tag: water22_6f9de073cbe38 X-Filterd-Recvd-Size: 2388 Date: Thu, 23 Apr 2015 16:09:25 -0400 From: Steven Rostedt To: Thomas Gleixner 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 Message-ID: <20150423160925.7d108eaa@gandalf.local.home> In-Reply-To: References: <20150423190825.714359844@goodmis.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1435 Lines: 37 On Thu, 23 Apr 2015 21:51:47 +0200 (CEST) Thomas Gleixner wrote: > 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. I was waiting for someone to point that out :-) Is the NMI code generic enough now to know that an NMI triggered, and we could detect that and ignore the latencies if one did. Or perhaps even add a tracepoint in the start and end of an NMI, to account for it, (add hooks there), in case there's any SMIs that sneak in after an NMI. I guess I could also add an NMI notifier to let me know. But I know how much everyone loves notifiers :-) > > Aside of that isn't there a way to detect SMI crap with performance > counters on recent hardware? > Nothing I know of that is generic enough. And just because an SMI triggers, doesn't mean it's bad if it is quick enough. We have had arguments with HW vendors about their SMIs, and used the hwlat_detector to show that their SMIs are not as innocent as they claim. But we also have seen SMIs trigger under 1us, where it doesn't affect the system. -- Steve -- 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/