linux-kernel - Re: [RFC][PATCH] perf: Rewrite core context handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <82000D4A-0A1B-4A8B-904C-24640215D2BD@fb.com>
Date:   Wed, 17 Oct 2018 16:43:27 +0000
From:   Song Liu <songliubraving@...com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     Alexey Budankov <alexey.budankov@...ux.intel.com>,
        Ingo Molnar <mingo@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        "acme@...nel.org" <acme@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Stephane Eranian <eranian@...gle.com>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "megha.dey@...el.com" <megha.dey@...el.com>,
        "frederic@...nel.org" <frederic@...nel.org>
Subject: Re: [RFC][PATCH] perf: Rewrite core context handling



> On Oct 17, 2018, at 4:06 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> 
> On Tue, Oct 16, 2018 at 06:28:10PM +0000, Song Liu wrote:
>>> How about this: 
>>> 
>>> 1. Keep multiple perf_cpu_context per CPU, just like before this patch. 
>>> 
>>> 2. For perf_event_context, add PMU as an order for the RB tree. 
>>> 
>>> 3. (hw) pmu->perf_cpu_context->ctx only has events for this PMU (and sw 
>>>  events moved to this context).
>>> 
>>> 4. task->perf_event_ctxp has events for all PMUs. 
>>> 
>>> With this path, we keep the existing perf_cpu_context/perf_event_context
>>> logic as-is, which I think is simp.ler than the new logic (with extra
>>> *_pmu_context). And it should also solve the problem. 
>>> 
>>> Does this make sense? If this doesn't look too broken, I am happy to
>>> draft RFC for it. 
>>> 
>> 
>> I am not sure whether you missed this one, or found it totally insane. 
>> Could you please share your comments on it? My gut feeling is that this 
>> would be a simpler patch to solve the problem (two hw PMUs). (It might 
>> be less efficient though). 
> 
> Ah, sorry, somehow this email got lost.
> 
> That makes task and cpu contexts wildly different, which will complicate
> matters I feel.
> 

I think we only need different logic when adding events to the task/cpu 
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 
task and cpu context. The difference is, the CPU context will not have
such events, because we never added such event to CPU context. 

Does this make sense? I could try draft a RFC to see how difficult it is. 

Thanks,
Song