From: Mark Rutland <mark.rutland@arm.com>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
David Hildenbrand <david@redhat.com>,
Donald Dutile <ddutile@redhat.com>,
Eric Chanudet <echanude@redhat.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Itaru Kitayama <itaru.kitayama@fujitsu.com>
Subject: Re: [PATCH v2 3/4] arm64: mm: Don't remap pgtables for allocate vs populate
Date: Fri, 12 Apr 2024 10:25:16 +0100 [thread overview]
Message-ID: <Zhj9_HFVVxEZqdnB@FVFF77S0Q05N> (raw)
In-Reply-To: <37336367-f876-4429-a8a6-f887fc7f69ee@arm.com>
On Fri, Apr 12, 2024 at 08:53:18AM +0100, Ryan Roberts wrote:
> Hi Mark,
>
> [...]
>
> > Does something like the below look ok to you? The trade-off performance-wise is
> > that late uses will still use the fixmap, and will redundantly zero the tables,
> > but the logic remains fairly simple, and I suspect the overhead for late
> > allocations might not matter since the bulk of late changes are non-allocating.
> > @@ -303,12 +301,18 @@ static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
> > pudval |= PUD_TABLE_PXN;
> > BUG_ON(!pgtable_alloc);
> > pmd_phys = pgtable_alloc(PMD_SHIFT);
> > +
> > + pmdp = pmd_set_fixmap(pmd_phys);
> > + init_clear_pgtable(pmdp);
> > +
> > __pud_populate(pudp, pmd_phys, pudval);
> > pud = READ_ONCE(*pudp);
> > + } else {
> > + pmdp = pmd_set_fixmap(pud_page_paddr(pud));
> > }
> > BUG_ON(pud_bad(pud));
> >
> > - pmdp = pmd_set_fixmap_offset(pudp, addr);
> > + pmdp += pmd_index(addr);
> > do {
> > pgprot_t __prot = prot;
> >
> > @@ -345,12 +349,18 @@ static void alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
> > p4dval |= P4D_TABLE_PXN;
> > BUG_ON(!pgtable_alloc);
> > pud_phys = pgtable_alloc(PUD_SHIFT);
> > +
> > + pudp = pud_set_fixmap(pud_phys);
> > + init_clear_pgtable(pudp);
> > +
> > __p4d_populate(p4dp, pud_phys, p4dval);
> > p4d = READ_ONCE(*p4dp);
> > + } else {
> > + pudp = pud_set_fixmap(p4d_page_paddr(p4d));
>
> With this change I end up in pgtable folding hell. pXX_set_fixmap() is defined
> as NULL when the level is folded (and pXX_page_paddr() is not defined at all).
> So it all compiles, but doesn't boot.
Sorry about that; I had not thought to check the folding logic when hacking
that up.
> I think the simplest approach is to follow this pattern:
>
> ----8<----
> @@ -340,12 +338,15 @@ static void alloc_init_pud(p4d_t *p4dp, unsigned long
> addr, unsigned long end,
> p4dval |= P4D_TABLE_PXN;
> BUG_ON(!pgtable_alloc);
> pud_phys = pgtable_alloc(PUD_SHIFT);
> + pudp = pud_set_fixmap(pud_phys);
> + init_clear_pgtable(pudp);
> + pudp += pud_index(addr);
> __p4d_populate(p4dp, pud_phys, p4dval);
> - p4d = READ_ONCE(*p4dp);
> + } else {
> + BUG_ON(p4d_bad(p4d));
> + pudp = pud_set_fixmap_offset(p4dp, addr);
> }
> - BUG_ON(p4d_bad(p4d));
>
> - pudp = pud_set_fixmap_offset(p4dp, addr);
> do {
> pud_t old_pud = READ_ONCE(*pudp);
> ----8<----
>
> For the map case, we continue to use pud_set_fixmap_offset() which is always
> defined (and always works correctly).
>
> Note also that the previously unconditional BUG_ON needs to be prior to the
> fixmap call to be useful, and its really only valuable in the map case because
> for the alloc case we are the ones setting the p4d so we already know its not
> bad. This means we don't need the READ_ONCE() in the alloc case.
>
> Shout if you disagree.
That looks good, and I agree with the reasoning here.
Thanks for working on this!
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:[~2024-04-12 9:25 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-04 14:33 [PATCH v2 0/4] Speed up boot with faster linear map creation Ryan Roberts
2024-04-04 14:33 ` [PATCH v2 1/4] arm64: mm: Don't remap pgtables per-cont(pte|pmd) block Ryan Roberts
2024-04-10 9:46 ` Mark Rutland
2024-04-10 10:27 ` Ryan Roberts
2024-04-04 14:33 ` [PATCH v2 2/4] arm64: mm: Batch dsb and isb when populating pgtables Ryan Roberts
2024-04-10 10:06 ` Mark Rutland
2024-04-10 10:25 ` Ryan Roberts
2024-04-10 11:06 ` Mark Rutland
2024-04-04 14:33 ` [PATCH v2 3/4] arm64: mm: Don't remap pgtables for allocate vs populate Ryan Roberts
2024-04-11 13:02 ` Mark Rutland
2024-04-11 13:37 ` Ryan Roberts
2024-04-11 14:48 ` Mark Rutland
2024-04-11 14:57 ` Ryan Roberts
2024-04-11 15:25 ` Mark Rutland
2024-04-11 15:37 ` Ryan Roberts
2024-04-12 7:53 ` Ryan Roberts
2024-04-12 9:25 ` Mark Rutland [this message]
2024-04-04 14:33 ` [PATCH v2 4/4] arm64: mm: Lazily clear pte table mappings from fixmap Ryan Roberts
2024-04-11 13:24 ` Mark Rutland
2024-04-11 13:39 ` Ryan Roberts
2024-04-05 7:39 ` [PATCH v2 0/4] Speed up boot with faster linear map creation Itaru Kitayama
2024-04-06 8:32 ` Ryan Roberts
2024-04-06 10:31 ` Itaru Kitayama
2024-04-08 7:30 ` Ryan Roberts
2024-04-09 0:10 ` Itaru Kitayama
2024-04-09 10:04 ` Ryan Roberts
2024-04-09 10:13 ` Itaru Kitayama
2024-04-09 11:22 ` David Hildenbrand
2024-04-09 11:29 ` David Hildenbrand
2024-04-09 11:51 ` David Hildenbrand
2024-04-09 14:13 ` Ryan Roberts
2024-04-09 14:29 ` David Hildenbrand
2024-04-09 14:39 ` Ryan Roberts
2024-04-09 14:45 ` David Hildenbrand
2024-04-09 23:30 ` Itaru Kitayama
2024-04-10 6:47 ` Itaru Kitayama
2024-04-10 7:10 ` David Hildenbrand
2024-04-10 7:37 ` Itaru Kitayama
2024-04-10 7:45 ` David Hildenbrand
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=Zhj9_HFVVxEZqdnB@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=david@redhat.com \
--cc=ddutile@redhat.com \
--cc=echanude@redhat.com \
--cc=itaru.kitayama@fujitsu.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ryan.roberts@arm.com \
--cc=will@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