From: Will Deacon <will@kernel.org>
To: Alexandre Ghiti <alex@ghiti.fr>
Cc: Ryan Roberts <ryan.roberts@arm.com>,
Alexandre Ghiti <alexghiti@rivosinc.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Matthew Wilcox <willy@infradead.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-mm@kvack.org
Subject: Re: [PATCH v5 0/9] Merge arm64/riscv hugetlbfs contpte support
Date: Thu, 8 May 2025 13:30:47 +0100 [thread overview]
Message-ID: <20250508123046.GA3706@willie-the-truck> (raw)
In-Reply-To: <84cb893a-46e3-408a-ba0e-2eff0b44d2a1@ghiti.fr>
Hi folks,
On Mon, May 05, 2025 at 06:08:50PM +0200, Alexandre Ghiti wrote:
> On 29/04/2025 16:09, Ryan Roberts wrote:
> > On 07/04/2025 13:04, Alexandre Ghiti wrote:
> > > Can someone from arm64 review this? I think it's preferable to share the same
> > > implementation between riscv and arm64.
> > I've been thinking about this for a while and had some conversations internally.
> > This patchset has both pros and cons.
> >
> > In the pros column, it increases code reuse in an area that has had quite of few
> > bugs popping up lately; so this would bring more eyes and hopefully higher
> > quality in the long run.
> >
> > But in the cons column, we have seen HW errata in similar areas in the past and
> > I'm nervous that by hoisting this code to mm, we make it harder to workaround
> > any future errata. Additionally I can imagine that this change could make it
> > harder to support future Arm architecture enhancements.
> >
> > I appreciate the cons are not strong *technical* arguments but nevertheless they
> > are winning out in this case; My opinion is that we should keep the arm64
> > implementations of huge_pte_ (and contpte_ too - I know you have a separate
> > series for this) private to arm64.
> >
> > Sorry about that.
> >
> > > The end goal is the support of mTHP using svnapot on riscv, which we want soon,
> > > so if that patchset does not gain any traction, I'll just copy/paste the arm64
> > > implementation into riscv.
> > This copy/paste approach would be my preference.
>
>
> I have to admit that I disagree with this approach, the riscv and arm64
> implementations are *exactly* the same so it sounds weird to duplicate code,
> the pros you mention outweigh the cons.
>
> Unless I'm missing something about the erratas? To me, that's easily fixed
> by providing arch specific overrides no? Can you describe what sort of
> erratas would not fit then?
If we start with the common implementation you have here, nothing
prevents us from forking the code in future if the architectures diverge
so I'd be inclined to merge this series and see how we get on. However,
one thing I *do* think we need to ensure is that the relevant folks from
both arm64 (i.e. Ryan) and riscv (i.e. Alexandre) are cc'd on changes to
the common code. Otherwise, it's going to be a step backwards in terms
of maintainability.
Could we add something to MAINTAINERS so that the new file picks you both
up as reviewers?
Will
next prev parent reply other threads:[~2025-05-08 12:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-21 13:06 Alexandre Ghiti
2025-03-21 13:06 ` [PATCH v5 1/9] riscv: Safely remove huge_pte_offset() when manipulating NAPOT ptes Alexandre Ghiti
2025-03-21 13:06 ` [PATCH v5 2/9] riscv: Restore the pfn in a NAPOT pte when manipulated by core mm code Alexandre Ghiti
2025-03-21 13:06 ` [PATCH v5 3/9] mm: Use common huge_ptep_get() function for riscv/arm64 Alexandre Ghiti
2025-03-21 13:06 ` [PATCH v5 4/9] mm: Use common set_huge_pte_at() " Alexandre Ghiti
2025-03-21 13:06 ` [PATCH v5 5/9] mm: Use common huge_pte_clear() " Alexandre Ghiti
2025-03-21 13:06 ` [PATCH v5 6/9] mm: Use common huge_ptep_get_and_clear() " Alexandre Ghiti
2025-03-21 13:06 ` [PATCH v5 7/9] mm: Use common huge_ptep_set_access_flags() " Alexandre Ghiti
2025-03-21 13:06 ` [PATCH v5 8/9] mm: Use common huge_ptep_set_wrprotect() " Alexandre Ghiti
2025-03-21 13:06 ` [PATCH v5 9/9] mm: Use common huge_ptep_clear_flush() " Alexandre Ghiti
2025-03-21 17:24 ` [PATCH v5 0/9] Merge arm64/riscv hugetlbfs contpte support Christophe Leroy
2025-03-25 12:36 ` Alexandre Ghiti
2025-04-07 12:04 ` Alexandre Ghiti
2025-04-29 14:09 ` Ryan Roberts
2025-05-05 16:08 ` Alexandre Ghiti
2025-05-08 12:30 ` Will Deacon [this message]
2025-05-09 11:09 ` Alexandre Ghiti
2025-05-09 13:02 ` Ryan Roberts
2025-05-21 14:57 ` Lorenzo Stoakes
2025-05-27 9:25 ` Alexandre Ghiti
2025-05-27 9:37 ` Lorenzo Stoakes
2025-05-28 14:51 ` Ryan Roberts
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=20250508123046.GA3706@willie-the-truck \
--to=will@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=alexghiti@rivosinc.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=ryan.roberts@arm.com \
--cc=willy@infradead.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