From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751771Ab3LSOye (ORCPT ); Thu, 19 Dec 2013 09:54:34 -0500 Received: from mga09.intel.com ([134.134.136.24]:60641 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750810Ab3LSOyd (ORCPT ); Thu, 19 Dec 2013 09:54:33 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.95,512,1384329600"; d="scan'208";a="427256841" From: Alexander Shishkin To: Peter Zijlstra Cc: Arnaldo Carvalho de Melo , Ingo Molnar , linux-kernel@vger.kernel.org, David Ahern , Frederic Weisbecker , Jiri Olsa , Mike Galbraith , Namhyung Kim , Paul Mackerras , Stephane Eranian , Andi Kleen Subject: Re: [PATCH v0 04/71] itrace: Infrastructure for instruction flow tracing units In-Reply-To: <20131219125759.GU3694@twins.programming.kicks-ass.net> References: <20131218133439.GR21999@twins.programming.kicks-ass.net> <8738lqtg0v.fsf@ashishki-desk.ger.corp.intel.com> <20131218141125.GT21999@twins.programming.kicks-ass.net> <87zjnys0gj.fsf@ashishki-desk.ger.corp.intel.com> <20131218150900.GU21999@twins.programming.kicks-ass.net> <87wqj1s2d3.fsf@ashishki-desk.ger.corp.intel.com> <20131219103134.GD30183@twins.programming.kicks-ass.net> <87ob4drsww.fsf@ashishki-desk.ger.corp.intel.com> <20131219112812.GY21999@twins.programming.kicks-ass.net> <20131219115759.GS3694@twins.programming.kicks-ass.net> <20131219125759.GU3694@twins.programming.kicks-ass.net> User-Agent: Notmuch/0.15.2+182~gd0bd88f (http://notmuchmail.org) Emacs/23.4.1 (x86_64-pc-linux-gnu) Date: Thu, 19 Dec 2013 16:54:27 +0200 Message-ID: <87eh58ki1o.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Peter Zijlstra writes: > On Thu, Dec 19, 2013 at 12:57:59PM +0100, Peter Zijlstra wrote: > So you're basically forced to stop the tracing on PMI anyhow; so your > continuous tracing argument goes out the window. It's only stopped inside the PMI handler to set up another buffer, and is then started again, so no useful trace is lost. PMI handler is not traced. What you're proposing is stopping it for good till perf collects the previous data, which will lose us a lot of trace. So my argument stands. Regards, -- Alex