From: Mark Rutland <mark.rutland@arm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "Steven Price" <steven.price@arm.com>,
x86@kernel.org, "Arnd Bergmann" <arnd@arndb.de>,
"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
"Jérôme Glisse" <jglisse@redhat.com>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Andy Lutomirski" <luto@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"James Morse" <james.morse@arm.com>,
"Will Deacon" <will@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
linux-arm-kernel@lists.infradead.org, "Liang,
Kan" <kan.liang@linux.intel.com>
Subject: Re: [PATCH v9 00/21] Generic page walk and ptdump
Date: Wed, 24 Jul 2019 15:07:35 +0100 [thread overview]
Message-ID: <20190724140735.GD2624@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1907241541570.1791@nanos.tec.linutronix.de>
On Wed, Jul 24, 2019 at 03:57:33PM +0200, Thomas Gleixner wrote:
> On Wed, 24 Jul 2019, Steven Price wrote:
> > On 23/07/2019 11:16, Mark Rutland wrote:
> > > Are there any visible changes to the arm64 output?
> >
> > arm64 output shouldn't change. I've confirmed that "efi_page_tables" is
> > identical on a Juno before/after the change. "kernel_page_tables"
> > obviously will vary depending on the exact layout of memory, but the
> > format isn't changed.
> >
> > x86 output does change due to patch 14. In this case the change is
> > removing the lines from the output of the form...
> >
> > > 0xffffffff84800000-0xffffffffa0000000 440M pmd
> >
> > ...which are unpopulated areas of the memory map. Populated lines which
> > have attributes are unchanged.
>
> Having the hole size and the level in the dump is a very conveniant thing.
Mhmm; I thought that we logged which level was empty on arm64 (but
apparently not), since knowing the structure can be important.
> Right now we have:
>
> 0xffffffffc0427000-0xffffffffc042b000 16K ro NX pte
> 0xffffffffc042b000-0xffffffffc042e000 12K RW NX pte
> 0xffffffffc042e000-0xffffffffc042f000 4K pte
> 0xffffffffc042f000-0xffffffffc0430000 4K ro x pte
> 0xffffffffc0430000-0xffffffffc0431000 4K ro NX pte
> 0xffffffffc0431000-0xffffffffc0433000 8K RW NX pte
> 0xffffffffc0433000-0xffffffffc0434000 4K pte
> 0xffffffffc0434000-0xffffffffc0436000 8K ro x pte
> 0xffffffffc0436000-0xffffffffc0438000 8K ro NX pte
> 0xffffffffc0438000-0xffffffffc043a000 8K RW NX pte
> 0xffffffffc043a000-0xffffffffc043f000 20K pte
> 0xffffffffc043f000-0xffffffffc0444000 20K ro x pte
> 0xffffffffc0444000-0xffffffffc0447000 12K ro NX pte
> 0xffffffffc0447000-0xffffffffc0449000 8K RW NX pte
> 0xffffffffc0449000-0xffffffffc044f000 24K pte
> 0xffffffffc044f000-0xffffffffc0450000 4K ro x pte
> 0xffffffffc0450000-0xffffffffc0451000 4K ro NX pte
> 0xffffffffc0451000-0xffffffffc0453000 8K RW NX pte
> 0xffffffffc0453000-0xffffffffc0458000 20K pte
> 0xffffffffc0458000-0xffffffffc0459000 4K ro x pte
> 0xffffffffc0459000-0xffffffffc045b000 8K ro NX pte
>
> with your change this becomes:
>
> 0xffffffffc0427000-0xffffffffc042b000 16K ro NX pte
> 0xffffffffc042b000-0xffffffffc042e000 12K RW NX pte
> 0xffffffffc042f000-0xffffffffc0430000 4K ro x pte
> 0xffffffffc0430000-0xffffffffc0431000 4K ro NX pte
> 0xffffffffc0431000-0xffffffffc0433000 8K RW NX pte
> 0xffffffffc0434000-0xffffffffc0436000 8K ro x pte
> 0xffffffffc0436000-0xffffffffc0438000 8K ro NX pte
> 0xffffffffc0438000-0xffffffffc043a000 8K RW NX pte
> 0xffffffffc043f000-0xffffffffc0444000 20K ro x pte
> 0xffffffffc0444000-0xffffffffc0447000 12K ro NX pte
> 0xffffffffc0447000-0xffffffffc0449000 8K RW NX pte
> 0xffffffffc044f000-0xffffffffc0450000 4K ro x pte
> 0xffffffffc0450000-0xffffffffc0451000 4K ro NX pte
> 0xffffffffc0451000-0xffffffffc0453000 8K RW NX pte
> 0xffffffffc0458000-0xffffffffc0459000 4K ro x pte
> 0xffffffffc0459000-0xffffffffc045b000 8K ro NX pte
>
> which is 5 lines less, but a pain to figure out the size of the holes. And
> it becomes even more painful when the holes go across different mapping
> levels.
I agree.
Steven, could you align arm64 with the x86 behaviour here?
Thanks,
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "Dave Hansen" <dave.hansen@linux.intel.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
"Steven Price" <steven.price@arm.com>,
linux-mm@kvack.org, "Jérôme Glisse" <jglisse@redhat.com>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Andy Lutomirski" <luto@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"James Morse" <james.morse@arm.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Will Deacon" <will@kernel.org>,
linux-arm-kernel@lists.infradead.org, "Liang,
Kan" <kan.liang@linux.intel.com>
Subject: Re: [PATCH v9 00/21] Generic page walk and ptdump
Date: Wed, 24 Jul 2019 15:07:35 +0100 [thread overview]
Message-ID: <20190724140735.GD2624@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1907241541570.1791@nanos.tec.linutronix.de>
On Wed, Jul 24, 2019 at 03:57:33PM +0200, Thomas Gleixner wrote:
> On Wed, 24 Jul 2019, Steven Price wrote:
> > On 23/07/2019 11:16, Mark Rutland wrote:
> > > Are there any visible changes to the arm64 output?
> >
> > arm64 output shouldn't change. I've confirmed that "efi_page_tables" is
> > identical on a Juno before/after the change. "kernel_page_tables"
> > obviously will vary depending on the exact layout of memory, but the
> > format isn't changed.
> >
> > x86 output does change due to patch 14. In this case the change is
> > removing the lines from the output of the form...
> >
> > > 0xffffffff84800000-0xffffffffa0000000 440M pmd
> >
> > ...which are unpopulated areas of the memory map. Populated lines which
> > have attributes are unchanged.
>
> Having the hole size and the level in the dump is a very conveniant thing.
Mhmm; I thought that we logged which level was empty on arm64 (but
apparently not), since knowing the structure can be important.
> Right now we have:
>
> 0xffffffffc0427000-0xffffffffc042b000 16K ro NX pte
> 0xffffffffc042b000-0xffffffffc042e000 12K RW NX pte
> 0xffffffffc042e000-0xffffffffc042f000 4K pte
> 0xffffffffc042f000-0xffffffffc0430000 4K ro x pte
> 0xffffffffc0430000-0xffffffffc0431000 4K ro NX pte
> 0xffffffffc0431000-0xffffffffc0433000 8K RW NX pte
> 0xffffffffc0433000-0xffffffffc0434000 4K pte
> 0xffffffffc0434000-0xffffffffc0436000 8K ro x pte
> 0xffffffffc0436000-0xffffffffc0438000 8K ro NX pte
> 0xffffffffc0438000-0xffffffffc043a000 8K RW NX pte
> 0xffffffffc043a000-0xffffffffc043f000 20K pte
> 0xffffffffc043f000-0xffffffffc0444000 20K ro x pte
> 0xffffffffc0444000-0xffffffffc0447000 12K ro NX pte
> 0xffffffffc0447000-0xffffffffc0449000 8K RW NX pte
> 0xffffffffc0449000-0xffffffffc044f000 24K pte
> 0xffffffffc044f000-0xffffffffc0450000 4K ro x pte
> 0xffffffffc0450000-0xffffffffc0451000 4K ro NX pte
> 0xffffffffc0451000-0xffffffffc0453000 8K RW NX pte
> 0xffffffffc0453000-0xffffffffc0458000 20K pte
> 0xffffffffc0458000-0xffffffffc0459000 4K ro x pte
> 0xffffffffc0459000-0xffffffffc045b000 8K ro NX pte
>
> with your change this becomes:
>
> 0xffffffffc0427000-0xffffffffc042b000 16K ro NX pte
> 0xffffffffc042b000-0xffffffffc042e000 12K RW NX pte
> 0xffffffffc042f000-0xffffffffc0430000 4K ro x pte
> 0xffffffffc0430000-0xffffffffc0431000 4K ro NX pte
> 0xffffffffc0431000-0xffffffffc0433000 8K RW NX pte
> 0xffffffffc0434000-0xffffffffc0436000 8K ro x pte
> 0xffffffffc0436000-0xffffffffc0438000 8K ro NX pte
> 0xffffffffc0438000-0xffffffffc043a000 8K RW NX pte
> 0xffffffffc043f000-0xffffffffc0444000 20K ro x pte
> 0xffffffffc0444000-0xffffffffc0447000 12K ro NX pte
> 0xffffffffc0447000-0xffffffffc0449000 8K RW NX pte
> 0xffffffffc044f000-0xffffffffc0450000 4K ro x pte
> 0xffffffffc0450000-0xffffffffc0451000 4K ro NX pte
> 0xffffffffc0451000-0xffffffffc0453000 8K RW NX pte
> 0xffffffffc0458000-0xffffffffc0459000 4K ro x pte
> 0xffffffffc0459000-0xffffffffc045b000 8K ro NX pte
>
> which is 5 lines less, but a pain to figure out the size of the holes. And
> it becomes even more painful when the holes go across different mapping
> levels.
I agree.
Steven, could you align arm64 with the x86 behaviour here?
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-07-24 14:07 UTC|newest]
Thread overview: 129+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-22 15:41 [PATCH v9 00/21] Generic page walk and ptdump Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` [PATCH v9 01/21] arc: mm: Add p?d_leaf() definitions Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` [PATCH v9 02/21] arm: " Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` [PATCH v9 03/21] arm64: " Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` [PATCH v9 04/21] mips: " Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 21:47 ` Paul Burton
2019-07-22 21:47 ` Paul Burton
2019-07-24 13:03 ` Steven Price
2019-07-24 13:03 ` Steven Price
2019-07-22 15:41 ` [PATCH v9 05/21] powerpc: " Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` [PATCH v9 06/21] riscv: " Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` [PATCH v9 07/21] s390: " Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` [PATCH v9 08/21] sparc: " Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` [PATCH v9 09/21] x86: " Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-22 15:41 ` [PATCH v9 10/21] mm: Add generic p?d_leaf() macros Steven Price
2019-07-22 15:41 ` Steven Price
2019-07-23 9:41 ` Mark Rutland
2019-07-23 9:41 ` Mark Rutland
2019-07-24 13:48 ` Steven Price
2019-07-24 13:48 ` Steven Price
2019-07-28 11:44 ` Anshuman Khandual
2019-07-28 11:44 ` Anshuman Khandual
2019-07-29 11:38 ` Steven Price
2019-07-29 11:38 ` Steven Price
2019-08-01 6:09 ` Anshuman Khandual
2019-08-01 6:09 ` Anshuman Khandual
2019-08-01 12:22 ` Steven Price
2019-08-01 12:22 ` Steven Price
2019-07-29 12:50 ` Mark Rutland
2019-07-29 12:50 ` Mark Rutland
2019-08-01 6:13 ` Anshuman Khandual
2019-08-01 6:13 ` Anshuman Khandual
2019-07-22 15:42 ` [PATCH v9 11/21] mm: pagewalk: Add p4d_entry() and pgd_entry() Steven Price
2019-07-22 15:42 ` Steven Price
2019-07-23 10:14 ` Mark Rutland
2019-07-23 10:14 ` Mark Rutland
2019-07-24 13:53 ` Steven Price
2019-07-24 13:53 ` Steven Price
2019-07-24 14:09 ` Mark Rutland
2019-07-24 14:09 ` Mark Rutland
2019-07-28 12:33 ` Anshuman Khandual
2019-07-28 12:33 ` Anshuman Khandual
2019-07-29 12:17 ` Steven Price
2019-07-29 12:17 ` Steven Price
2019-07-22 15:42 ` [PATCH v9 12/21] mm: pagewalk: Allow walking without vma Steven Price
2019-07-22 15:42 ` Steven Price
2019-07-28 14:20 ` Anshuman Khandual
2019-07-28 14:20 ` Anshuman Khandual
2019-07-29 12:29 ` Steven Price
2019-07-29 12:29 ` Steven Price
2019-08-01 6:41 ` Anshuman Khandual
2019-08-01 6:41 ` Anshuman Khandual
2019-07-22 15:42 ` [PATCH v9 13/21] mm: pagewalk: Add test_p?d callbacks Steven Price
2019-07-22 15:42 ` Steven Price
2019-07-28 13:41 ` Anshuman Khandual
2019-07-28 13:41 ` Anshuman Khandual
2019-07-29 12:34 ` Steven Price
2019-07-29 12:34 ` Steven Price
2019-07-22 15:42 ` [PATCH v9 14/21] x86: mm: Don't display pages which aren't present in debugfs Steven Price
2019-07-22 15:42 ` Steven Price
2019-07-22 15:42 ` [PATCH v9 15/21] x86: mm: Point to struct seq_file from struct pg_state Steven Price
2019-07-22 15:42 ` Steven Price
2019-07-22 15:42 ` [PATCH v9 16/21] x86: mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct Steven Price
2019-07-22 15:42 ` Steven Price
2019-07-22 15:42 ` [PATCH v9 17/21] x86: mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct Steven Price
2019-07-22 15:42 ` Steven Price
2019-07-22 15:42 ` [PATCH v9 18/21] x86: mm: Convert ptdump_walk_pgd_level_core() " Steven Price
2019-07-22 15:42 ` Steven Price
2019-07-22 15:42 ` [PATCH v9 19/21] mm: Add generic ptdump Steven Price
2019-07-22 15:42 ` Steven Price
2019-07-23 9:57 ` Mark Rutland
2019-07-23 9:57 ` Mark Rutland
2019-07-24 16:36 ` Steven Price
2019-07-24 16:36 ` Steven Price
2019-07-29 2:59 ` Anshuman Khandual
2019-07-29 2:59 ` Anshuman Khandual
2019-07-29 13:56 ` Steven Price
2019-07-29 13:56 ` Steven Price
2019-07-22 15:42 ` [PATCH v9 20/21] x86: mm: Convert dump_pagetables to use walk_page_range Steven Price
2019-07-22 15:42 ` Steven Price
2019-07-22 15:42 ` [PATCH v9 21/21] arm64: mm: Convert mm/dump.c to use walk_page_range() Steven Price
2019-07-22 15:42 ` Steven Price
2019-07-23 6:39 ` [PATCH v9 00/21] Generic page walk and ptdump Anshuman Khandual
2019-07-23 6:39 ` Anshuman Khandual
2019-07-24 13:35 ` Steven Price
2019-07-24 13:35 ` Steven Price
2019-07-25 9:09 ` Anshuman Khandual
2019-07-25 9:09 ` Anshuman Khandual
2019-07-25 9:30 ` Will Deacon
2019-07-25 9:30 ` Will Deacon
2019-07-26 6:03 ` Anshuman Khandual
2019-07-26 6:03 ` Anshuman Khandual
2019-07-25 10:15 ` Steven Price
2019-07-25 10:15 ` Steven Price
2019-07-23 10:16 ` Mark Rutland
2019-07-23 10:16 ` Mark Rutland
2019-07-24 13:35 ` Steven Price
2019-07-24 13:35 ` Steven Price
2019-07-24 13:57 ` Thomas Gleixner
2019-07-24 13:57 ` Thomas Gleixner
2019-07-24 14:07 ` Mark Rutland [this message]
2019-07-24 14:07 ` Mark Rutland
2019-07-24 14:18 ` Steven Price
2019-07-24 14:18 ` Steven Price
2019-07-24 14:37 ` Thomas Gleixner
2019-07-24 14:37 ` Thomas Gleixner
2019-07-28 11:20 ` Anshuman Khandual
2019-07-28 11:20 ` Anshuman Khandual
2019-07-29 11:32 ` Steven Price
2019-07-29 11:32 ` Steven Price
2019-07-31 9:27 ` Sven Schnelle
2019-07-31 9:27 ` Sven Schnelle
2019-07-31 11:18 ` Steven Price
2019-07-31 11:18 ` Steven Price
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=20190724140735.GD2624@lakrids.cambridge.arm.com \
--to=mark.rutland@arm.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=jglisse@redhat.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=steven.price@arm.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@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 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.