From: kajoljain <kjain@linux.ibm.com>
To: Jiri Olsa <jolsa@redhat.com>,
Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: maddy@linux.ibm.com, linuxppc-dev@lists.ozlabs.org,
jolsa@kernel.org, acme@kernel.org
Subject: Re: [PATCH] tools/perf: Fix powerpc gap between kernel end and module start
Date: Mon, 18 Jan 2021 15:51:07 +0530 [thread overview]
Message-ID: <dd8b772b-fa13-975b-be42-2b7bdf14b46d@linux.ibm.com> (raw)
In-Reply-To: <20210112093811.GA1272772@krava>
On 1/12/21 3:08 PM, Jiri Olsa wrote:
> On Mon, Dec 28, 2020 at 09:14:14PM -0500, Athira Rajeev wrote:
>
> SNIP
>
>> c000000002799370 b backtrace_flag
>> c000000002799378 B radix_tree_node_cachep
>> c000000002799380 B __bss_stop
>> c0000000027a0000 B _end
>> c008000003890000 t icmp_checkentry [ip_tables]
>> c008000003890038 t ipt_alloc_initial_table [ip_tables]
>> c008000003890468 T ipt_do_table [ip_tables]
>> c008000003890de8 T ipt_unregister_table_pre_exit [ip_tables]
>> ...
>>
>> Perf calls function symbols__fixup_end() which sets the end of symbol
>> to 0xc008000003890000, which is the next address and this is the start
>> address of first module (icmp_checkentry in above) which will make the
>> huge symbol size of 0x80000010f0000.
>>
>> After symbols__fixup_end:
>> symbols__fixup_end: sym->name: _end, sym->start: 0xc0000000027a0000,
>> sym->end: 0xc008000003890000
>>
>> On powerpc, kernel text segment is located at 0xc000000000000000
>> whereas the modules are located at very high memory addresses,
>> 0xc00800000xxxxxxx. Since the gap between end of kernel text segment
>> and beginning of first module's address is high, histogram allocation
>> using calloc fails.
>>
>> Fix this by detecting the kernel's last symbol and limiting
>> the range of last kernel symbol to pagesize.
Patch looks good to me.
Tested-By: Kajol Jain<kjain@linux.ibm.com>
Thanks,
Kajol Jain
>>
>> Signed-off-by: Athira Rajeev<atrajeev@linux.vnet.ibm.com>
>
> I can't test, but since the same approach works for arm and s390,
> this also looks ok
>
> Acked-by: Jiri Olsa <jolsa@redhat.com>
>
> thanks,
> jirka
>
>> ---
>> tools/perf/arch/powerpc/util/Build | 1 +
>> tools/perf/arch/powerpc/util/machine.c | 24 ++++++++++++++++++++++++
>> 2 files changed, 25 insertions(+)
>> create mode 100644 tools/perf/arch/powerpc/util/machine.c
>>
>> diff --git a/tools/perf/arch/powerpc/util/Build b/tools/perf/arch/powerpc/util/Build
>> index e86e210bf514..b7945e5a543b 100644
>> --- a/tools/perf/arch/powerpc/util/Build
>> +++ b/tools/perf/arch/powerpc/util/Build
>> @@ -1,4 +1,5 @@
>> perf-y += header.o
>> +perf-y += machine.o
>> perf-y += kvm-stat.o
>> perf-y += perf_regs.o
>> perf-y += mem-events.o
>> diff --git a/tools/perf/arch/powerpc/util/machine.c b/tools/perf/arch/powerpc/util/machine.c
>> new file mode 100644
>> index 000000000000..c30e5cc88c16
>> --- /dev/null
>> +++ b/tools/perf/arch/powerpc/util/machine.c
>> @@ -0,0 +1,24 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +#include <stdio.h>
>> +#include <string.h>
>> +#include <internal/lib.h> // page_size
>> +#include "debug.h"
>> +#include "symbol.h"
>> +
>> +/* On powerpc kernel text segment start at memory addresses, 0xc000000000000000
>> + * whereas the modules are located at very high memory addresses,
>> + * for example 0xc00800000xxxxxxx. The gap between end of kernel text segment
>> + * and beginning of first module's text segment is very high.
>> + * Therefore do not fill this gap and do not assign it to the kernel dso map.
>> + */
>> +
>> +void arch__symbols__fixup_end(struct symbol *p, struct symbol *c)
>> +{
>> + if (strchr(p->name, '[') == NULL && strchr(c->name, '['))
>> + /* Limit the range of last kernel symbol */
>> + p->end += page_size;
>> + else
>> + p->end = c->start;
>> + pr_debug4("%s sym:%s end:%#lx\n", __func__, p->name, p->end);
>> +}
>> --
>> 1.8.3.1
>>
>
next prev parent reply other threads:[~2021-01-18 10:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-29 2:14 [PATCH] tools/perf: Fix powerpc gap between kernel end and module start Athira Rajeev
2021-01-12 9:38 ` Jiri Olsa
2021-01-13 6:44 ` Athira Rajeev
2021-01-18 10:21 ` kajoljain [this message]
2021-02-02 10:32 ` Athira Rajeev
2021-02-03 15:31 ` Arnaldo Carvalho de Melo
2021-02-04 12:11 ` Athira Rajeev
2021-02-09 12:47 ` Arnaldo Carvalho de Melo
2021-02-11 12:19 ` Athira Rajeev
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=dd8b772b-fa13-975b-be42-2b7bdf14b46d@linux.ibm.com \
--to=kjain@linux.ibm.com \
--cc=acme@kernel.org \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.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 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).