Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Song Liu <songliubraving@fb.com>
To:     Peter Zijlstra <peterz@infradead.org>
CC:     Ingo Molnar <mingo@kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        "acme@kernel.org" <acme@kernel.org>,
        "alexander.shishkin@linux.intel.com" 
        <alexander.shishkin@linux.intel.com>,
        "jolsa@redhat.com" <jolsa@redhat.com>,
        "eranian@google.com" <eranian@google.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "alexey.budankov@linux.intel.com" <alexey.budankov@linux.intel.com>,
        "mark.rutland@arm.com" <mark.rutland@arm.com>,
        "megha.dey@intel.com" <megha.dey@intel.com>,
        "frederic@kernel.org" <frederic@kernel.org>
Subject: Re: [RFC][PATCH] perf: Rewrite core context handling
Thread-Topic: [RFC][PATCH] perf: Rewrite core context handling
Thread-Index: AQHUYIaFJ/VvvMmSxkC06uIJGGK3pKUZrRIAgAAbn4CAANwqgIAAu/qAgAF8bACABM0pAIAAcKMA
Date:   Tue, 16 Oct 2018 16:34:05 +0000
Message-ID: <9865C981-0E8C-4419-AE8C-638DCD40D74E@fb.com>
References: <20181010104559.GO5728@hirez.programming.kicks-ass.net>
 <D2014055-9B25-4152-A582-7AD42A3837AB@fb.com>
 <20181011092913.GA9848@hirez.programming.kicks-ass.net>
 <70079805-1CAE-4CAA-813A-F8DDB929F22B@fb.com>
 <20181012095001.GG9867@hirez.programming.kicks-ass.net>
 <E4F81A5E-C371-429D-AFEC-6F4B32971F09@fb.com>
 <20181016095056.GE4030@hirez.programming.kicks-ass.net>
In-Reply-To: <20181016095056.GE4030@hirez.programming.kicks-ass.net>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A641A2C667C2B14EAFBB00E70A52D4DE@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6a0208e4-863f-4453-ab06-08d633853088
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2018 16:34:05.6012
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1296
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-16_11:,,
 signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Oct 16, 2018, at 2:50 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>=20
> On Sat, Oct 13, 2018 at 08:31:37AM +0000, Song Liu wrote:
>=20
>> The only suggestion I have right now is on which struct owns which
>> data:
>>=20
>> 1. perf_cpu_context owns two perf_event_context: ctx and *task_ctx.=20
>>   This is the same as right now.=20
>=20
>> 2. perf_event_context owns multiple perf_event_pmu_context:=20
>>   One perf_event_pmu_context for software groups;
>>   One perf_event_pmu_context for each hardware PMU.
>=20
> It does now already, right? Through the pmu_ctx_list we can, given an
> perf_event_context, find all associated perf_event_pmu_context's.

Yes, this is very similar to right now. It is related to #4, #5 below.=20
With current patch, perf_cpu_pmu_context is more like the "owner" of
the per CPU perf_event_pmu_context. I feel it is more natural that=20
perf_cpu_context is the owner of perf_event_pmu_context, while the
perf_cpu_pmu_context doesn't own anything.=20

Again, the difference to current patch is very small.=20

>=20
>> 3. perf_event_pmu_context owns RB tree of events. Since we don't=20
>>   need rotation across multiple hardware PMUs, the rotation is=20
>>   within same perf_event_pmu_context. =20
>=20
> By keeping the RB trees in perf_event_context, we get bigger trees,
> which is more efficient (log(n+m) < log(n) + log(m))
>=20
> Also, specifically, it means we only need a single merge sort /
> iteration to schedule in a full context, instead of (again) doing 'n' of
> them.
>=20
> Also, given a context and a pmu, it is cheaper for finding the relevant
> events; this is needed for big.little for instance. Something the
> proposed patch doesn't fully flesh out.

Would it be faster if we add a perf_event_pmu_context pointer to the=20
perf_event? I think a group on hw PMU-a should never know a group on
hw PMU-b. So some separation would make things simpler.=20

Thanks,
Song