Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752063AbbLNOqe (ORCPT ); Mon, 14 Dec 2015 09:46:34 -0500 Received: from mail-ob0-f174.google.com ([209.85.214.174]:34688 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751830AbbLNOqc (ORCPT ); Mon, 14 Dec 2015 09:46:32 -0500 Subject: Re: [PATCHSET 00/16] perf top: Add multi-thread support (v1) To: Peter Zijlstra 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> Cc: Ingo Molnar , Namhyung Kim , Namhyung Kim , Arnaldo Carvalho de Melo , Jiri Olsa , LKML , Frederic Weisbecker , Andi Kleen , Stephane Eranian , Adrian Hunter From: David Ahern Message-ID: <566ED644.2010601@gmail.com> Date: Mon, 14 Dec 2015 07:46:28 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151214092613.GL6357@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1925 Lines: 42 On 12/14/15 2:26 AM, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 08:01:31AM -0700, David Ahern wrote: >> On 12/11/15 1:11 AM, Ingo Molnar wrote: >>> >>> * Namhyung Kim wrote: >>> >>>> IIRC David said that thread per cpu seems too much especially on a large system >>>> (like ~1024 cpu). [...] >>> >>> Too much in what fashion? For recording I think it's the fastest, most natural >>> model - anything else will create cache line bounces. >> >> The intrusiveness of perf on the system under observation. I understand >> there are a lot of factors that go into it. > > So I can see some of that, if every cpu has its own thread then every > cpu will occasionally schedule that thread. Whereas if there were less, > you'd not have that. > > Still, I think it makes sense to implement it, we need the multi-file > option anyway. Once we have that, we can also implement a per-node > option, which should be a fairly simple hybrid of the two approaches. > > The thing is, perf-record is really struggling on big machines. I've gone from the 1024-cpu sparc systems earlier this year down to small PPC and Rangeley-based switches. For both ends of the scale (and in between) I constantly struggle with the options to manage memory, cpu and disk consumption. There definitely needs to be options (e.g., multi-threaded on/off). For the threading options I get the appeal for 1-thread per cpu but other options make sense as well -- 1 thread per core, 1 per NUMA node. perf has the CPU topology so should not be too difficult. If you have 1-thread per cpu that means you are pinning the threads to the cpu? That brings in additional permissions problems. -- 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/