From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754377AbbLJItw (ORCPT ); Thu, 10 Dec 2015 03:49:52 -0500 Received: from mail-pa0-f53.google.com ([209.85.220.53]:32897 "EHLO mail-pa0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752141AbbLJItv (ORCPT ); Thu, 10 Dec 2015 03:49:51 -0500 User-Agent: K-9 Mail for Android In-Reply-To: <20151210080118.GA8664@gmail.com> References: <1449734015-9148-1-git-send-email-namhyung@kernel.org> <20151210080118.GA8664@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [PATCHSET 00/16] perf top: Add multi-thread support (v1) From: Namhyung Kim Date: Thu, 10 Dec 2015 17:49:35 +0900 To: Ingo Molnar , Namhyung Kim CC: Arnaldo Carvalho de Melo , Peter Zijlstra , Jiri Olsa , LKML , David Ahern , Frederic Weisbecker , Andi Kleen , Stephane Eranian , Adrian Hunter Message-ID: <5E6F0F13-9696-45F1-A0E8-CA0B95020D10@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On December 10, 2015 5:01:18 PM GMT+09:00, Ingo Molnar wrote: > >* Namhyung Kim wrote: > >> Hello, >> >> This patchset if an attempt to support multi-threading in perf top. >> In fact, perf top already run on two threads - a worker thread and a >> display thread. However processing all samples with a single thread >> in a large machine can have scalability problems. >> >> This patchset extends it to have multiple worker threads to process >> samples concurrently. Users can control the number of threads using >> --num-thread option. And there's a collector thread for passing >hist >> entries from worker threads to the display thread. > >Could you please make the number of threads default to the number of >CPUs? > >Since perf top is doing one perf event per CPU anyway, that's a pretty >natural >model. > >( I think 'perf record' should use per CPU threads as well to receive >events, to >address the 'IO overload' problems with -g recording on larger CPU >counts. ) IIRC David said that thread per cpu seems too much especially on a large system (like ~1024 cpu). I have no idea what's the reasonable default on the system, so I chose 1/4 of map buffers (i.e. cpus for most cases). But I think I should take non-system-wide mode into account too. Thanks Namhyung Hi Ingo, -- Sent from my Android device with K-9 Mail. Please excuse my brevity.