Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753375AbbLNRws (ORCPT ); Mon, 14 Dec 2015 12:52:48 -0500 Received: from mail.kernel.org ([198.145.29.136]:49297 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752542AbbLNRwq (ORCPT ); Mon, 14 Dec 2015 12:52:46 -0500 Date: Mon, 14 Dec 2015 14:52:42 -0300 From: Arnaldo Carvalho de Melo To: Peter Zijlstra Cc: David Ahern , Ingo Molnar , Namhyung Kim , Namhyung Kim , Jiri Olsa , LKML , Frederic Weisbecker , Andi Kleen , Stephane Eranian , Adrian Hunter Subject: Re: [PATCHSET 00/16] perf top: Add multi-thread support (v1) Message-ID: <20151214175242.GV6843@kernel.org> References: <1449734015-9148-1-git-send-email-namhyung@kernel.org> <20151210080118.GA8664@gmail.com> <5E6F0F13-9696-45F1-A0E8-CA0B95020D10@gmail.com> <20151211081141.GA21600@gmail.com> <566AE54B.1010702@gmail.com> <20151214092613.GL6357@twins.programming.kicks-ass.net> <20151214093841.GB30347@gmail.com> <566ED864.1040500@gmail.com> <20151214162655.GS6843@kernel.org> <20151214164130.GS6357@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151214164130.GS6357@twins.programming.kicks-ass.net> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1577 Lines: 35 Em Mon, Dec 14, 2015 at 05:41:30PM +0100, Peter Zijlstra escreveu: > On Mon, Dec 14, 2015 at 01:26:55PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Mon, Dec 14, 2015 at 07:55:32AM -0700, David Ahern escreveu: > > > On 12/14/15 2:38 AM, Ingo Molnar wrote: > > > > > > > >>And in an unrelated note, I absolutely detest --buildid being the > > > >>default, it makes perf-record blow chunks. > > > Multiple things here, .debug/ should be size limited, and buildid > > processing doesn't need necessarily to store things in that cache, I bet > > what PeterZ is complaining about is the reprocessing of events at the > > end of the session, to find out about the PERF_RECORD_MMAP* events to > > then read the build-ids and insert then into the perf.data file header. > > > > Yeah, its the reprocessing that is taking forever.. On my moderately > sized system with 40 CPUs, the reprocessing is taking about as long as > the actual workload, which is tedious. Right, I thought about using some dummy event for tracking mmaps, which I think is a technique used by the Intel PT code (well, there it uses it for sched_switches) will check... > Once I figured out what was happening Jiri was quick to point out I > should be using -B. Right, we have to have sane behaviour by default, damn long/high freq workloads, duh ;-) - Arnaldo -- 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/