[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZXDEyzVcBOPUCCpg@slm.duckdns.org>
Date: Wed, 6 Dec 2023 09:00:27 -1000
From: Tejun Heo <tj@...nel.org>
To: Alexandre Ghiti <alex@...ti.fr>
Cc: Alexandre Ghiti <alexghiti@...osinc.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Andrey Ryabinin <ryabinin.a.a@...il.com>,
Alexander Potapenko <glider@...gle.com>,
Andrey Konovalov <andreyknvl@...il.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Vincenzo Frascino <vincenzo.frascino@....com>,
Arnd Bergmann <arnd@...db.de>, Dennis Zhou <dennis@...nel.org>,
Christoph Lameter <cl@...ux.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
kasan-dev@...glegroups.com, linux-arch@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH 0/2] riscv: Enable percpu page first chunk allocator
On Wed, Dec 06, 2023 at 11:08:20AM +0100, Alexandre Ghiti wrote:
> Hi Tejun,
>
> On 10/11/2023 15:07, Alexandre Ghiti wrote:
> > While working with pcpu variables, I noticed that riscv did not support
> > first chunk allocation in the vmalloc area which may be needed as a fallback
> > in case of a sparse NUMA configuration.
> >
> > patch 1 starts by introducing a new function flush_cache_vmap_early() which
> > is needed since a new vmalloc mapping is established and directly accessed:
> > on riscv, this would likely fail in case of a reordered access or if the
> > uarch caches invalid entries in TLB.
> >
> > patch 2 simply enables the page percpu first chunk allocator in riscv.
> >
> > Alexandre Ghiti (2):
> > mm: Introduce flush_cache_vmap_early() and its riscv implementation
> > riscv: Enable pcpu page first chunk allocator
> >
> > arch/riscv/Kconfig | 2 ++
> > arch/riscv/include/asm/cacheflush.h | 3 ++-
> > arch/riscv/include/asm/tlbflush.h | 2 ++
> > arch/riscv/mm/kasan_init.c | 8 ++++++++
> > arch/riscv/mm/tlbflush.c | 5 +++++
> > include/asm-generic/cacheflush.h | 6 ++++++
> > mm/percpu.c | 8 +-------
> > 7 files changed, 26 insertions(+), 8 deletions(-)
> >
>
> Any feedback regarding this?
On cursory look, it looked fine to me but Dennis is maintaining the percpu
tree now. Dennis?
Thanks.
--
tejun
Powered by blists - more mailing lists