[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181017110651.GI3121@hirez.programming.kicks-ass.net>
Date: Wed, 17 Oct 2018 13:06:51 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Song Liu <songliubraving@...com>
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 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.
Powered by blists - more mailing lists