All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ravi Bangoria <ravi.bangoria@amd.com>
To: peterz@infradead.org
Cc: acme@kernel.org, alexander.shishkin@linux.intel.com,
	jolsa@redhat.com, namhyung@kernel.org, songliubraving@fb.com,
	eranian@google.com, alexey.budankov@linux.intel.com,
	ak@linux.intel.com, mark.rutland@arm.com, megha.dey@intel.com,
	frederic@kernel.org, maddy@linux.ibm.com, irogers@google.com,
	kim.phillips@amd.com, linux-kernel@vger.kernel.org,
	santosh.shukla@amd.com
Subject: Re: [RFC v2] perf: Rewrite core context handling
Date: Mon, 31 Jan 2022 10:13:09 +0530	[thread overview]
Message-ID: <5c6a53dc-99f2-cb82-5aee-05d9b5061b42@amd.com> (raw)
In-Reply-To: <20220113134743.1292-1-ravi.bangoria@amd.com>



On 13-Jan-22 7:17 PM, Ravi Bangoria wrote:
> From: Peter Zijlstra <peterz@infradead.org>
> 
> This is the 2nd version of RFC originally posted by Peter[1].
> 
> There have been various issues and limitations with the way perf uses
> (task) contexts to track events. Most notable is the single hardware
> PMU task context, which has resulted in a number of yucky things (both
> proposed and merged).
> 
> Notably:
>  - HW breakpoint PMU
>  - ARM big.little PMU / Intel ADL PMU
>  - Intel Branch Monitoring PMU
>  - AMD IBS
> 
> Current design:
> ---------------
> Currently we have a per task and per cpu perf_event_contexts:
> 
>   task_struct::perf_events_ctxp[] <-> perf_event_context <-> perf_cpu_context
>        ^                                 |    ^     |
>        `---------------------------------'    |     `--> pmu
>                                               v           ^
>                                          perf_event ------'
> 
> Each task has an array of pointers to a perf_event_context. Each
> perf_event_context has a direct relation to a PMU and a group of
> events for that PMU. The task related perf_event_context's have a
> pointer back to that task.
> 
> Each PMU has a per-cpu pointer to a per-cpu perf_cpu_context, which
> includes a perf_event_context, which again has a direct relation to
> that PMU, and a group of events for that PMU.
> 
> The perf_cpu_context also tracks which task context is currently
> associated with that CPU and includes a few other things like the
> hrtimer for rotation etc.
> 
> Each perf_event is then associated with its PMU and one
> perf_event_context.
> 
> Proposed design:
> ----------------
> New design proposed by this patch reduce to a single task context and
> a single CPU context but adds some intermediate data-structures:
> 
>   task_struct::perf_event_ctxp -> perf_event_context <- perf_cpu_context
>        ^                                 |    ^ ^
>        `---------------------------------'    | |
>                                               | |    perf_cpu_pmu_context
>                                               | `----.    ^
>                                               |      |    |
>                                               |      v    v
>                                               | ,--> perf_event_pmu_context
>                                               | |         ^
>                                               | |         |
>                                               v v         v
>                                          perf_event ---> pmu
> 
> With new design, perf_event_context will hold all pmu events in the
> respective(pinned/flexible) rbtrees. This can be achieved by adding
> pmu to rbtree key:
> 
>   {cpu, pmu, cgroup_id, group_index}
> 
> Each perf_event_context carry a list of perf_event_pmu_context which
> is used to hold per-pmu-per-context state. For ex, it keeps track of
> currently active events for that pmu, a pmu specific task_ctx_data,
> a flag to tell whether rotation is required or not etc.
> 
> Similarly perf_cpu_pmu_context is used to hold per-pmu-per-cpu state
> like hrtimer details to drive the event rotation, a pointer to
> perf_event_pmu_context of currently running task and some other
> ancillary information.
> 
> Each perf_event is associated to it's pmu, perf_event_context and
> perf_event_pmu_context.
> 
> Original RFC -> RFC v2:
> -----------------------
> In addition to porting the patch to latest (v5.16-rc6) kernel, here
> are some of the major changes between two revisions:
> 
> - There were quite a bit of fundamental changes since original patch.
>   Most notably a rbtree key has changed from {cpu,group_index} to
>   {cpu,cgroup_id,group_index}. Adding a pmu key in between as proposed
>   in original patch is not straight forward as it will break cgroup
>   specific optimization. Hence we need to iterate over all pmu_ctx
>   for a given ctx and call visit_groups_merge() one by one.
> - Enabled cgroup support (CGROUP_PERF).
> - Some changes wrt multiplexing events as with new design the rotation
>   happens at cgroup subtree unlike at pmu subtree in original patch.
> 
> Because of additional complexity above changes bring in, I thought to
> get initial review about the overall approach before starting to make it
> upstream ready. Hence this patch just provides an idea of the direction
> we will head toward. Many loose ends in the patch rightnow. Like, I've
> not paid much attention to synchronization related aspects. Similarly,
> some of the issues marked in original patch (XXX) haven't been fixed.
> 
> A simple perf stat/record/top survives with the patch but machine
> crashes with first run of perf test (stale cpc->task_epc causing the
> crash). Lockdep is also screaming a lot :)

Hi Peter, can you please review this.

Thanks,
Ravi

  parent reply	other threads:[~2022-01-31  4:43 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-13 13:47 [RFC v2] perf: Rewrite core context handling Ravi Bangoria
2022-01-13 19:06 ` [RFC PATCH] perf: find_get_pmu_context can be static kernel test robot
2022-01-13 19:15 ` [RFC v2] perf: Rewrite core context handling kernel test robot
2022-01-17  7:18 ` [perf] f7cf7134e4: WARNING:at_kernel/events/core.c:#__pmu_ctx_sched_out kernel test robot
2022-01-17  7:18   ` kernel test robot
2022-01-31  4:43 ` Ravi Bangoria [this message]
2022-06-13 14:35 ` [RFC v2] perf: Rewrite core context handling Peter Zijlstra
2022-06-13 14:36   ` Peter Zijlstra
2022-06-13 14:38   ` Peter Zijlstra
2022-08-02  6:11     ` Ravi Bangoria
2022-08-22 15:29       ` Peter Zijlstra
2022-08-22 15:43         ` Peter Zijlstra
2022-08-22 16:37           ` Ravi Bangoria
2022-08-23  4:20             ` Ravi Bangoria
2022-08-29  3:54               ` Ravi Bangoria
2022-08-23  6:30             ` Peter Zijlstra
2022-08-29  4:00             ` Ravi Bangoria
2022-08-29 11:58               ` Peter Zijlstra
2022-08-22 16:52       ` Peter Zijlstra
2022-08-23  4:57         ` Ravi Bangoria
2022-06-13 14:41   ` Peter Zijlstra
2022-08-22 14:38     ` Ravi Bangoria
2022-06-13 14:43   ` Peter Zijlstra
2022-08-02  6:16     ` Ravi Bangoria
2022-08-23  8:57       ` Peter Zijlstra
2022-08-24  5:07         ` Ravi Bangoria
2022-08-24  7:27           ` Peter Zijlstra
2022-08-24  7:53             ` Ravi Bangoria
2022-06-13 14:55   ` Peter Zijlstra
2022-08-02  6:10     ` Ravi Bangoria
2022-08-22 16:44       ` Peter Zijlstra
2022-08-23  4:46         ` Ravi Bangoria
2022-06-17 13:36   ` Peter Zijlstra
2022-08-24 10:13     ` Peter Zijlstra
2022-06-27  4:18   ` Ravi Bangoria
2022-08-02  6:06     ` Ravi Bangoria
2022-08-24 12:15   ` Peter Zijlstra
2022-08-24 14:59     ` Peter Zijlstra
2022-08-25  5:39       ` Ravi Bangoria
2022-08-25  9:17         ` Peter Zijlstra
2022-08-25 11:03       ` Ravi Bangoria
2022-08-02  6:13 ` Ravi Bangoria
2022-08-23  7:10   ` Peter Zijlstra
2022-08-02  6:17 ` Ravi Bangoria
2022-08-23  7:26   ` Peter Zijlstra
2022-08-23 15:14     ` Ravi Bangoria
2022-08-22 14:40 ` Ravi Bangoria
2022-01-14 21:48 kernel test robot
2022-01-18  6:01 ` kernel test robot
2022-01-18  6:01   ` kernel test robot

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=5c6a53dc-99f2-cb82-5aee-05d9b5061b42@amd.com \
    --to=ravi.bangoria@amd.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexey.budankov@linux.intel.com \
    --cc=eranian@google.com \
    --cc=frederic@kernel.org \
    --cc=irogers@google.com \
    --cc=jolsa@redhat.com \
    --cc=kim.phillips@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maddy@linux.ibm.com \
    --cc=mark.rutland@arm.com \
    --cc=megha.dey@intel.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=santosh.shukla@amd.com \
    --cc=songliubraving@fb.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.