From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21436 invoked by alias); 24 Jan 2013 15:46:53 -0000 Received: (qmail 21421 invoked by uid 22791); 24 Jan 2013 15:46:52 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-ee0-f47.google.com (HELO mail-ee0-f47.google.com) (74.125.83.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Jan 2013 15:46:41 +0000 Received: by mail-ee0-f47.google.com with SMTP id e52so4640291eek.20 for ; Thu, 24 Jan 2013 07:46:40 -0800 (PST) X-Received: by 10.14.174.73 with SMTP id w49mr7523710eel.17.1359042400698; Thu, 24 Jan 2013 07:46:40 -0800 (PST) Received: from gmail.com (2E6BC28D.catv.pool.telekom.hu. [46.107.194.141]) by mx.google.com with ESMTPS id e2sm35689953eeo.8.2013.01.24.07.46.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 24 Jan 2013 07:46:40 -0800 (PST) Date: Thu, 24 Jan 2013 15:46:00 -0000 From: Ingo Molnar To: markus.t.metzger@intel.com Cc: mingo@redhat.com, mingo@elte.hu, linux-kernel@vger.kernel.org, Mark Kettenis , Pedro Alves , Jan Kratochvil , gdb-patches@sourceware.org Subject: Re: [PATCH] x86, perf, bts: disable BTS from Nehalem to Ivy Bridge Message-ID: <20130124154637.GB32146@gmail.com> References: <1354876511-25294-1-git-send-email-markus.t.metzger@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1354876511-25294-1-git-send-email-markus.t.metzger@intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00595.txt.bz2 * markus.t.metzger@intel.com wrote: > From: Markus Metzger > > Starting with Nehalem, the BTS "from" information may in some cases be > incorrect (AAJ122). > > This has been detected while adding branch tracing support to gdb, where it > results in sporadic test fails. > > Disable BTS support on Nehalem, Westmere, Sandy Bridge, and Ivy Bridge. But the failures are rare, so the BTS data is still correct statistically, by and large, right? So why not just keep it as-is and teach tooling to be more robust about implausible trace entries? It has to be ready for that eventuality *anyway*. Thanks, Ingo