From: Rashmica Gupta <rashmicy@gmail.com>
To: Oliver O'Halloran <oohall@gmail.com>, linuxppc-dev@lists.ozlabs.org
Cc: Rashmica Gupta <rashmica.g@gmail.com>
Subject: Re: [PATCH 2/2] powerpc/mm: add phys addr to linux page table dump
Date: Wed, 12 Apr 2017 14:22:50 +1000 [thread overview]
Message-ID: <a36aef1c-9310-2123-56a8-9eeea9540f0d@gmail.com> (raw)
In-Reply-To: <20170331013749.17874-2-oohall@gmail.com>
On 31/03/17 12:37, Oliver O'Halloran wrote:
> The current page table dumper scans the linux page tables and coalesces
> mappings with adjacent virtual addresses and similar PTE flags. This
> behaviour is somewhat broken when you consider the IOREMAP space where
> entirely unrelated mappings will appear to be contiguous. This patch
> modifies the range coalescing so that only ranges that are both physically
> and virtually contiguous are combined. This patch also adds to the dump
> output the physical address at the start of each range.
>
> Cc: Rashmica Gupta <rashmica.g@gmail.com>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
> ---
> arch/powerpc/mm/dump_linuxpagetables.c | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/mm/dump_linuxpagetables.c b/arch/powerpc/mm/dump_linuxpagetables.c
> index e7cbfd5a0940..85e6a45bd7ee 100644
> --- a/arch/powerpc/mm/dump_linuxpagetables.c
> +++ b/arch/powerpc/mm/dump_linuxpagetables.c
> @@ -56,6 +56,8 @@ struct pg_state {
> struct seq_file *seq;
> const struct addr_marker *marker;
> unsigned long start_address;
> + unsigned long start_pa;
> + unsigned long last_pa;
> unsigned int level;
> u64 current_flags;
> };
> @@ -265,7 +267,9 @@ static void dump_addr(struct pg_state *st, unsigned long addr)
> const char *unit = units;
> unsigned long delta;
>
> - seq_printf(st->seq, "0x%016lx-0x%016lx ", st->start_address, addr-1);
> + seq_printf(st->seq, "0x%016lx-0x%016lx ", st->start_address, addr-1);
> + seq_printf(st->seq, "%016lx ", st->start_pa);
> +
> delta = (addr - st->start_address) >> 10;
> /* Work out what appropriate unit to use */
> while (!(delta & 1023) && unit[1]) {
> @@ -280,11 +284,15 @@ static void note_page(struct pg_state *st, unsigned long addr,
> unsigned int level, u64 val)
> {
> u64 flag = val & pg_level[level].mask;
> + u64 pa = val & PTE_RPN_MASK;
> +
> /* At first no level is set */
> if (!st->level) {
> st->level = level;
> st->current_flags = flag;
> st->start_address = addr;
> + st->start_pa = pa;
> + st->last_pa = pa;
> seq_printf(st->seq, "---[ %s ]---\n", st->marker->name);
> /*
> * Dump the section of virtual memory when:
> @@ -292,9 +300,11 @@ static void note_page(struct pg_state *st, unsigned long addr,
> * - we change levels in the tree.
> * - the address is in a different section of memory and is thus
> * used for a different purpose, regardless of the flags.
> + * - the pa of this page is not adjacent to the last inspected page
> */
> } else if (flag != st->current_flags || level != st->level ||
> - addr >= st->marker[1].start_address) {
> + addr >= st->marker[1].start_address ||
> + pa != st->last_pa + PAGE_SIZE) {
>
> /* Check the PTE flags */
> if (st->current_flags) {
> @@ -318,8 +328,12 @@ static void note_page(struct pg_state *st, unsigned long addr,
> seq_printf(st->seq, "---[ %s ]---\n", st->marker->name);
> }
> st->start_address = addr;
> + st->start_pa = pa;
> + st->last_pa = pa;
> st->current_flags = flag;
> st->level = level;
> + } else {
> + st->last_pa = pa;
> }
> }
>
Makes sense to me!
Reviewed-by: Rashmica Gupta <rashmica.g@gmail.com>
next prev parent reply other threads:[~2017-04-12 4:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-31 1:37 [PATCH 1/2] powerpc/mm: fix up pgtable dump flags Oliver O'Halloran
2017-03-31 1:37 ` [PATCH 2/2] powerpc/mm: add phys addr to linux page table dump Oliver O'Halloran
2017-04-12 4:22 ` Rashmica Gupta [this message]
2017-04-12 4:19 ` [PATCH 1/2] powerpc/mm: fix up pgtable dump flags Rashmica Gupta
2017-04-12 6:52 ` Michael Ellerman
2017-04-13 2:48 ` Oliver O'Halloran
2017-04-13 5:39 ` Michael Ellerman
2017-04-13 11:23 ` [1/2] " Michael Ellerman
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=a36aef1c-9310-2123-56a8-9eeea9540f0d@gmail.com \
--to=rashmicy@gmail.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=oohall@gmail.com \
--cc=rashmica.g@gmail.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).