Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753755AbbDQSUm (ORCPT ); Fri, 17 Apr 2015 14:20:42 -0400 Received: from one.firstfloor.org ([193.170.194.197]:35337 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751560AbbDQSUj (ORCPT ); Fri, 17 Apr 2015 14:20:39 -0400 Date: Fri, 17 Apr 2015 20:20:37 +0200 From: Andi Kleen To: Peter Zijlstra Cc: "Liang, Kan" , "linux-kernel@vger.kernel.org" , "mingo@kernel.org" , "acme@infradead.org" , "eranian@google.com" , "andi@firstfloor.org" Subject: Re: [PATCH V6 4/6] perf, x86: handle multiple records in PEBS buffer Message-ID: <20150417182037.GZ2366@two.firstfloor.org> References: <1428597466-8154-1-git-send-email-kan.liang@intel.com> <1428597466-8154-5-git-send-email-kan.liang@intel.com> <20150416125342.GZ23123@twins.programming.kicks-ass.net> <20150417081100.GZ24151@twins.programming.kicks-ass.net> <37D7C6CF3E00A74B8858931C1DB2F077017CB364@SHSMSX103.ccr.corp.intel.com> <20150417131237.GH23123@twins.programming.kicks-ass.net> <37D7C6CF3E00A74B8858931C1DB2F077017CBD09@SHSMSX103.ccr.corp.intel.com> <20150417144407.GJ23123@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150417144407.GJ23123@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1814 Lines: 41 On Fri, Apr 17, 2015 at 04:44:07PM +0200, Peter Zijlstra wrote: > On Fri, Apr 17, 2015 at 02:19:58PM +0000, Liang, Kan wrote: > > > > But that brings us to patch 1 of this series, how is that correct in the face of > > > this? There is an arbitrary delay (A->B) added to the period. > > > And the Changelog of course never did bother to make that clear. That's how perf and other profilers always behaved. The PMI is not part of the period. The automatic PEBS reload is not in any way different. It's much faster than a PMI, but it's also not zero cost. This is not a gap in measurement though -- there is no other code running during that time on that CPU. It's simply overhead from the measurement mechanism. > > > > OK. I will update the changelog for patch 1 as below. > > --- > > When a fixed period is specified, this patch make perf use the PEBS > > auto reload mechanism. This makes normal profiling faster, because > > it avoids one costly MSR write in the PMI handler. > > > However, the reset value will be loaded by hardware assist. There is > > a little bit delay compared to previous non-auto-reload mechanism. > > The delay is arbitrary but very small. > > What is very small? And doesn't that mean its significant at exactly the > point this patch series is aimed at, namely very short period. The assist cost is 400-800 cycles, assuming common cases with everything cached. The minimum period the patch currently uses is 10000. In that extreme case it can be ~10% if cycles are used. -Andi -- ak@linux.intel.com -- Speaking for myself only. -- 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/