From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753258AbdFPJK2 (ORCPT ); Fri, 16 Jun 2017 05:10:28 -0400 Received: from foss.arm.com ([217.140.101.70]:53812 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753009AbdFPJK0 (ORCPT ); Fri, 16 Jun 2017 05:10:26 -0400 Date: Fri, 16 Jun 2017 10:09:38 +0100 From: Mark Rutland To: Alexey Budankov Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , Andi Kleen , Kan Liang , Dmitri Prokhorov , Valery Cherepennikov , David Carrillo-Cisneros , Stephane Eranian , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/n] perf/core: addressing 4x slowdown during per-process profiling of STREAM benchmark on Intel Xeon Phi Message-ID: <20170616090938.GB20092@leverpostej> References: <09226446-39b9-9bd2-d60f-b9bb947987c5@linux.intel.com> <20170615195618.GA8807@leverpostej> <07a76338-4c71-569a-d36e-7d6bcd10bd74@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07a76338-4c71-569a-d36e-7d6bcd10bd74@linux.intel.com> 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 On Fri, Jun 16, 2017 at 01:10:10AM +0300, Alexey Budankov wrote: > On 15.06.2017 22:56, Mark Rutland wrote: > >On Thu, Jun 15, 2017 at 08:41:42PM +0300, Alexey Budankov wrote: > >>This series of patches continues v2 and addresses captured comments. > >>Specifically this patch replaces pinned_groups and flexible_groups > >>lists of perf_event_context by red-black cpu indexed trees avoiding > >>data structures duplication and introducing possibility to iterate > >>event groups for a specific CPU only. > > > >If you use --per-thread, I take it the overhead is significantly > >lowered? > > Please ask more. IIUC, you're seeing the slowdown when using perf record, correct? There's a --per-thread option to ask perf record to not duplicate the event per-cpu. If you use that, what amount of slowdown do you see? It might be preferable to not open task-bound per-cpu events on systems with large cpu counts, and it would be good to know what the trade-off looks like for this case. > >>+static void > >>+perf_cpu_tree_insert(struct rb_root *tree, struct perf_event *event) > >>+{ > >>+ struct rb_node **node; > >>+ struct rb_node *parent; > >>+ > >>+ WARN_ON_ONCE(!tree || !event); > >>+ > >>+ node = &tree->rb_node; > >>+ parent = *node; > > > >The first iteration of the loop handles this, so it can go. > > If tree is empty parent will be uninitialized what is harmful. Sorry; my bad. Thanks, Mark.