public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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

  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