public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Song Liu <songliubraving@fb.com>
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
Date: Thu, 11 Oct 2018 11:29:13 +0200	[thread overview]
Message-ID: <20181011092913.GA9848@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <D2014055-9B25-4152-A582-7AD42A3837AB@fb.com>

On Thu, Oct 11, 2018 at 07:50:23AM +0000, Song Liu wrote:
> Hi Peter, 
> 
> I am trying to understand this. Pardon me if any question is silly. 
> 
> I am not sure I fully understand the motivation here. I guess we
> see problem when there are two (or more) independent hardware PMUs 
> per cpu? Then on a given cpu, there are two (or more) 
> perf_cpu_context, but only one task context? 

Right.

> If this is correct (I really doubt...), I guess perf_rotate_context()
> is the problem? 

No, everything comes apart. Where would you put the events of the second
PMU?

The thing most often proposed it pretending the second PMU is a
'software' PMU and sticking the events on the software PMU context.

But because software PMUs must never fail to schedule an event, that
results in some quite horrible things -- including that we cannot RR the
events.

Similarly the big.little guys have the problem that the PMUs are not the
same between big and little cores, and they fudge something horrible. By
having clear ordering on PMU, that can be cleaned up too.

> And if this is still correct, this patch may not help,
> as we are doing rotation for each perf_cpu_pmu_context? (or rotation 
> per perf_event_context is the next step?). 

We do indeed to rotation per perf_cpu_pmu_context, however:

 - perf_cpu_pmu_context embeds a cpu scope perf_event_pmu_context,
 - perf_cpu_pmu_context tracks the currently associated task scope
   perf_event_pmu_context.

So it can rotate all current events for a particular PMU.

> Or step back a little... I see two big changes:
> 
> 1. struct perf_ctx_context is now per cpu (instead of per pmu per cpu);
> 2. one perf_event_ctxp per task_struct (instead of 2).  

Correct, we reduce to 1 cpu context and 1 task context at all times.
This in fact simplifies quite a bit of things.

> I think #1 is a bigger change than #2. Is this correct? 

They're the 'same' change. But yes the primary purpose was 2, but having
only a single cpu context is a direct consequence.

> Could you please help me understand it better? 

I hope this helps to understand, please feel free to ask more.

  reply	other threads:[~2018-10-11  9:29 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-10 10:45 [RFC][PATCH] perf: Rewrite core context handling Peter Zijlstra
2018-10-11  7:50 ` Song Liu
2018-10-11  9:29   ` Peter Zijlstra [this message]
2018-10-11 22:37     ` Song Liu
2018-10-12  9:50       ` Peter Zijlstra
2018-10-12 14:25         ` Peter Zijlstra
2018-10-13  8:31         ` Song Liu
2018-10-16  9:50           ` Peter Zijlstra
2018-10-16 16:34             ` Song Liu
2018-10-16 18:10               ` Peter Zijlstra
2018-10-16 18:24                 ` Song Liu
2018-10-12  7:04     ` Alexey Budankov
2018-10-12 11:54       ` Peter Zijlstra
2018-10-15  7:26 ` Alexey Budankov
2018-10-15  8:34   ` Peter Zijlstra
2018-10-15  8:53     ` Peter Zijlstra
2018-10-15 17:29     ` Alexey Budankov
2018-10-15 18:31       ` Stephane Eranian
2018-10-16  6:39         ` Alexey Budankov
2018-10-16  9:32         ` Peter Zijlstra
2018-10-15 22:09     ` Song Liu
2018-10-16 18:28       ` Song Liu
2018-10-17 11:06         ` Peter Zijlstra
2018-10-17 16:43           ` Song Liu
2018-10-17 17:19             ` Peter Zijlstra
2018-10-17 18:33               ` Peter Zijlstra
2018-10-17 18:57                 ` Song Liu
2018-10-16 16:26 ` Mark Rutland
2018-10-16 18:07   ` Peter Zijlstra
2018-10-17  8:57 ` Alexey Budankov
2018-10-17 15:01   ` Alexander Shishkin
2018-10-17 15:58     ` Alexey Budankov
2018-10-17 16:30   ` Peter Zijlstra
2018-10-18  7:05     ` Alexey Budankov
2018-10-22 13:26 ` Alexander Shishkin
2018-10-23  6:13 ` Song Liu
2018-10-23  6:55   ` Peter Zijlstra
2019-05-15 11:17 ` Alexander Shishkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181011092913.GA9848@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexey.budankov@linux.intel.com \
    --cc=eranian@google.com \
    --cc=frederic@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=megha.dey@intel.com \
    --cc=mingo@kernel.org \
    --cc=songliubraving@fb.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox