Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S935267AbcKJRCN (ORCPT <rfc822;w@1wt.eu>);
        Thu, 10 Nov 2016 12:02:13 -0500
Received: from foss.arm.com ([217.140.101.70]:54012 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S934368AbcKJRCL (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 10 Nov 2016 12:02:11 -0500
Date: Thu, 10 Nov 2016 17:01:33 +0000
From: Mark Rutland <mark.rutland@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: kan.liang@intel.com, mingo@redhat.com, linux-kernel@vger.kernel.org,
        acme@kernel.org, tglx@linutronix.de,
        alexander.shishkin@linux.intel.com, vince@deater.net,
        eranian@google.com, andi@firstfloor.org
Subject: Re: [PATCH] perf/core: introduce context per CPU event list
Message-ID: <20161110170132.GI4418@leverpostej>
References: <1478718286-12824-1-git-send-email-kan.liang@intel.com>
 <20161110083355.GO3568@worktop.programming.kicks-ass.net>
 <20161110110516.GA4418@leverpostej>
 <20161110113704.GU3142@twins.programming.kicks-ass.net>
 <20161110120423.GC4418@leverpostej>
 <20161110121253.GX3142@twins.programming.kicks-ass.net>
 <20161110122618.GD4418@leverpostej>
 <20161110125804.GT3117@twins.programming.kicks-ass.net>
 <20161110141037.GE4418@leverpostej>
 <20161110162632.GY3142@twins.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161110162632.GY3142@twins.programming.kicks-ass.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1111
Lines: 30

On Thu, Nov 10, 2016 at 05:26:32PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 10, 2016 at 02:10:37PM +0000, Mark Rutland wrote:
> 
> > Sure, that sounds fine for scheduling (including big.LITTLE).
> > 
> > I might still be misunderstanding something, but I don't think that
> > helps Kan's case: since INACTIVE events which will fail their filters
> > (including the CPU check) will still be in the tree, they will still
> > have to be iterated over.
> > 
> > That is, unless we also sort the tree by event->cpu, or if in those
> > cases we only care about ACTIVE events and can use an active list.
> 
> A few emails back up I wrote:
> 
> >> If we stick all events in an RB-tree sorted on: {pmu,cpu,runtime} we

Ah, sorry. Clearly I wouldn't pass a reading comprehension test today.

> Looking at the code there's also cgroup muck, not entirely sure where in
> the sort order that should go if at all.
> 
> But having pmu and cpu in there would cure the big-little and
> per-task-per-cpu event issues.

Yup, that all makes sense to me now (modulo the cgroup stuff I also
haven't considered yet).

Thanks,
Mark.