From: Adrian Hunter <adrian.hunter@intel.com>
To: Leo Yan <leo.yan@arm.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Ian Rogers <irogers@google.com>,
Namhyung Kim <namhyung@kernel.org>,
James Clark <james.clark@arm.com>,
Athira Rajeev <atrajeev@linux.vnet.ibm.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/3] perf maps: Sort kcore maps
Date: Wed, 22 May 2024 13:31:19 +0300 [thread overview]
Message-ID: <2f4fce9f-6283-40ad-8adc-c370e98627da@intel.com> (raw)
In-Reply-To: <20240520090647.949371-2-leo.yan@arm.com>
On 20/05/24 12:06, Leo Yan wrote:
> When merging kcore maps into the kernel maps, it has an implicit
> requirement for the kcore maps ordering, otherwise, some sections
> delivered by the kcore maps will be ignored.
perf treats the kernel text map as a special case. The problem
is that the kcore loading logic did not cater for there being 2
maps that covered the kernel mapping.
The workaround was to choose the smaller mapping, but then that
still only worked if that was the first.
James essentially fixed that by ensuring the kernel "replacement"
map is inserted first.
In other respects, the ordering of the maps does not matter, so
I am not sure it is worth this extra processing.
>
> Let's see below example:
>
> Ordering 1:
> Kcore maps | Start address | End address
> -----------------+--------------------+--------------------
> kcore_text | 0xffff800080000000 | 0xffff8000822f0000
> vmalloc | 0xffff800080000000 | 0xfffffdffbf800000
>
> Ordering 2:
> Kcore maps | Start address | End address
> -----------------+--------------------+--------------------
> vmalloc | 0xffff800080000000 | 0xfffffdffbf800000
> kcore_text | 0xffff800080000000 | 0xffff8000822f0000
>
> The 'kcore_text' map is a subset of the 'vmalloc' map. When merging
> these two maps into the kernal maps with the maps__merge_in() function,
> the ordering 1 inserts the 'kcore_text' map prior to the 'vmalloc' map,
> thus the 'kcore_text' map will be respected. On the other hand, if maps
> are inserted with the ordering 2, the 'vmalloc' is inserted ahead, as a
> result, its subset map will be ignored afterwards.
>
> To merge the maps in a reliable way, this commit sorts the kcore maps
> before merging them. Besides sorting the maps based on the end address,
> it also gives the priority to a subset map to insert it before its
> superset map in the list.
>
> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
> tools/perf/util/symbol.c | 50 +++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index 9e5940b5bc59..c1513976ab6e 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -1256,6 +1256,7 @@ static int kcore_mapfn(u64 start, u64 len, u64 pgoff, void *data)
> {
> struct kcore_mapfn_data *md = data;
> struct map_list_node *list_node = map_list_node__new();
> + struct map_list_node *node;
>
> if (!list_node)
> return -ENOMEM;
> @@ -1269,8 +1270,55 @@ static int kcore_mapfn(u64 start, u64 len, u64 pgoff, void *data)
> map__set_end(list_node->map, map__start(list_node->map) + len);
> map__set_pgoff(list_node->map, pgoff);
>
> - list_add(&list_node->node, &md->maps);
> + list_for_each_entry(node, &md->maps, node) {
> + /*
> + * When the new map (list_node)'s end address is less than
> + * current node, it can be divided into three cases.
> + *
> + * Case 1: the new map does not overlap with the current node,
> + * as the new map's end address is less than the current node's
> + * start address.
> + * [*******node********]
> + * [***list_node***] `start `end
> + * `start `end
> + *
> + * Case 2: the new map overlaps with the current node.
> + *
> + * ,start ,end
> + * [*******node********]
> + * [***list_node***]
> + * `start `end
> + *
> + * Case 3: the new map is subset of the current node.
> + *
> + * ,start ,end
> + * [*******node********]
> + * [***list_node***]
> + * `start `end
> + *
> + * For above three cases, insert the new map node before the
> + * current node.
> + */
> + if (map__end(node->map) > map__end(list_node->map))
> + break;
> +
> + /*
> + * When the new map is subset of the current node and both nodes
> + * have the same end address, insert the new map node before the
> + * current node.
> + *
> + * ,start ,end
> + * [*******node********]
> + * [***list_node***]
> + * `start `end
> + */
> + if ((map__end(node->map) == map__end(list_node->map)) &&
> + (map__start(node->map) <= map__start(list_node->map)))
> + break;
> + }
>
> + /* Insert the new node (list_node) ahead */
> + list_add_tail(&list_node->node, &node->node);
> return 0;
> }
>
next prev parent reply other threads:[~2024-05-22 10:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-20 9:06 [PATCH v3 0/3] perf maps: Improve the kcore maps merging Leo Yan
2024-05-20 9:06 ` [PATCH v3 1/3] perf maps: Sort kcore maps Leo Yan
2024-05-22 10:31 ` Adrian Hunter [this message]
2024-05-25 9:29 ` Leo Yan
2024-05-28 15:00 ` James Clark
2024-05-29 8:45 ` Adrian Hunter
2024-05-20 9:06 ` [PATCH v3 2/3] perf maps: Remove the kernel text map with maps__remove_maps() Leo Yan
2024-05-22 11:27 ` Adrian Hunter
2024-05-20 9:06 ` [PATCH v3 3/3] perf maps: Remove the replacement of kernel map Leo Yan
2024-05-22 8:57 ` Adrian Hunter
2024-05-28 15:33 ` James Clark
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=2f4fce9f-6283-40ad-8adc-c370e98627da@intel.com \
--to=adrian.hunter@intel.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=jolsa@kernel.org \
--cc=leo.yan@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=namhyung@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).