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:     Alexey Budankov <alexey.budankov@linux.intel.com>,
        Ingo Molnar <mingo@kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        "acme@kernel.org" <acme@kernel.org>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Jiri Olsa <jolsa@redhat.com>,
        Stephane Eranian <eranian@google.com>,
        "Thomas Gleixner" <tglx@linutronix.de>,
        "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/VvvMmSxkC06uIJGGK3pKUf754AgAATMgCAAOOBAIABVJuAgAEXCYCAAF4KAIAACjKAgAAUdwCAAAbFAA==
Date:   Wed, 17 Oct 2018 18:57:25 +0000
Message-ID: <26D16201-2CEE-4D4A-B2FD-8F472B48A273@fb.com>
References: <20181010104559.GO5728@hirez.programming.kicks-ass.net>
 <3a738a08-2295-a4e9-dce7-a3e2b2ad794e@linux.intel.com>
 <20181015083448.GN9867@hirez.programming.kicks-ass.net>
 <AF0FCD08-E014-4D29-B023-EA780056DBB5@fb.com>
 <FE66AE20-9785-4CF7-8D8D-CF2A9C696923@fb.com>
 <20181017110651.GI3121@hirez.programming.kicks-ass.net>
 <82000D4A-0A1B-4A8B-904C-24640215D2BD@fb.com>
 <20181017171955.GQ3121@hirez.programming.kicks-ass.net>
 <20181017183310.GB2603@hirez.programming.kicks-ass.net>
In-Reply-To: <20181017183310.GB2603@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: <E748E1C605DD684AB35C3A4276BF477C@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8c639f59-03ff-4e3d-cf3d-08d6346260cc
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2018 18:57:25.2316
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1198
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-16_14:,,
 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 17, 2018, at 11:33 AM, Peter Zijlstra <peterz@infradead.org> wrote=
:
>=20
> On Wed, Oct 17, 2018 at 07:19:55PM +0200, Peter Zijlstra wrote:
>> On Wed, Oct 17, 2018 at 04:43:27PM +0000, Song Liu wrote:
>>=20
>>>> That makes task and cpu contexts wildly different, which will complica=
te
>>>> matters I feel.
>>>>=20
>>>=20
>>> I think we only need different logic when adding events to the task/cpu=
=20
>>> contexts. The ctx_sched_in() and ctx_sched_out() will need some extra
>>> logic to filter out events that are not being scheduled (don't schedule
>>> events on PMU-a when rotating PMU-b). This logic will be the same for=20
>>> task and cpu context. The difference is, the CPU context will not have
>>> such events, because we never added such event to CPU context.=20
>>>=20
>>> Does this make sense? I could try draft a RFC to see how difficult it i=
s.=20
>>=20
>> I'm not sure it saves much, if we have multiple per-cpu contexts we get
>> to re-introduce the active_ctx_list and loose the simplification for the
>> online status.
>>=20
>> Plus that fundamental assymetry -- which would bother my OCD forever
>> more :-)
>=20
> Worse, the whole syscall that installs the events will come apart. The
> locking for the two cases is different :/

I agree... I didn't get into details of locking. I just consider these all
as part of "adding event to context".=20

I believe this patch should give close to the optimal performance. However,=
=20
I do feel it makes the logic more complicate. Before this patch, perf_cpu_c=
ontext
and perf_event_context don't need to know much about multiple PMUs. With
this patch, the two extra *_pmu_context are necessary for performance (and
maybe also for correctness).=20

If we take first a baby step, how about adding more perf_event_ctx to=20
task_struct->perf_event_ctxp? We need one sw perf_event_ctx and a few hw=20
perf_event_ctx (one for each hw PMU). (I haven't checked whether it is OK
to allocate these when attaching events). (And I guess you don't really=20
like this..)

On the other hand, this patch makes it possible to create groups of events
from different hw PMUs. I guess that will be useful.=20

Thanks,
Song=