From: Catalin Marinas <catalin.marinas@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: guoren <guoren@kernel.org>,
Charlie Jenkins <charlie@rivosinc.com>,
Richard Henderson <richard.henderson@linaro.org>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>,
Vineet Gupta <vgupta@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
"James E . J . Bottomley" <James.Bottomley@hansenpartnership.com>,
Helge Deller <deller@gmx.de>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Naveen N Rao <naveen@kernel.org>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
"David S . Miller" <davem@davemloft.net>,
Andreas Larsson <andreas@gaisler.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Muchun Song <muchun.song@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
shuah <shuah@kernel.org>, Christoph Hellwig <hch@infradead.org>,
Michal Hocko <mhocko@suse.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Chris Torek <chris.torek@gmail.com>,
Linux-Arch <linux-arch@vger.kernel.org>,
linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
loongarch@lists.linux.dev, linux-mips@vger.kernel.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
sparclinux@vger.kernel.org, linux-mm@kvack.org,
linux-kselftest@vger.kernel.org,
linux-abi-devel@lists.sourceforge.net
Subject: Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
Date: Fri, 6 Sep 2024 12:43:44 +0100 [thread overview]
Message-ID: <Ztrq8PBLJ3QuFJz7@arm.com> (raw)
In-Reply-To: <f23b18c6-1856-4b59-9ba3-59809b425c81@app.fastmail.com>
On Fri, Sep 06, 2024 at 09:55:42AM +0000, Arnd Bergmann wrote:
> On Fri, Sep 6, 2024, at 09:14, Guo Ren wrote:
> > On Fri, Sep 6, 2024 at 3:18 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >> It's also unclear to me how we want this flag to interact with
> >> the existing logic in arch_get_mmap_end(), which attempts to
> >> limit the default mapping to a 47-bit address space already.
> >
> > To optimize RISC-V progress, I recommend:
> >
> > Step 1: Approve the patch.
> > Step 2: Update Go and OpenJDK's RISC-V backend to utilize it.
> > Step 3: Wait approximately several iterations for Go & OpenJDK
> > Step 4: Remove the 47-bit constraint in arch_get_mmap_end()
>
> I really want to first see a plausible explanation about why
> RISC-V can't just implement this using a 47-bit DEFAULT_MAP_WINDOW
> like all the other major architectures (x86, arm64, powerpc64),
FWIW arm64 actually limits DEFAULT_MAP_WINDOW to 48-bit in the default
configuration. We end up with a 47-bit with 16K pages but for a
different reason that has to do with LPA2 support (I doubt we need this
for the user mapping but we need to untangle some of the macros there;
that's for a separate discussion).
That said, we haven't encountered any user space problems with a 48-bit
DEFAULT_MAP_WINDOW. So I also think RISC-V should follow a similar
approach (47 or 48 bit default limit). Better to have some ABI
consistency between architectures. One can still ask for addresses above
this default limit via mmap().
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: guoren <guoren@kernel.org>,
Charlie Jenkins <charlie@rivosinc.com>,
Richard Henderson <richard.henderson@linaro.org>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>,
Vineet Gupta <vgupta@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
"James E . J . Bottomley" <James.Bottomley@hansenpartnership.com>,
Helge Deller <deller@gmx.de>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Naveen N Rao <naveen@kernel.org>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
"David S . Miller" <davem@davemloft.net>,
Andreas Larsson <andreas@gaisler.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Muchun Song <muchun.song@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
shuah <shuah@kernel.org>, Christoph Hellwig <hch@infradead.org>,
Michal Hocko <mhocko@suse.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Chris Torek <chris.torek@gmail.com>,
Linux-Arch <linux-arch@vger.kernel.org>,
linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
loongarch@lists.linux.dev, linux-mips@vger.kernel.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
sparclinux@vger.kernel.org, linux-mm@kvack.org,
linux-kselftest@vger.kernel.org,
linux-abi-devel@lists.sourceforge.net
Subject: Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
Date: Fri, 6 Sep 2024 12:43:44 +0100 [thread overview]
Message-ID: <Ztrq8PBLJ3QuFJz7@arm.com> (raw)
In-Reply-To: <f23b18c6-1856-4b59-9ba3-59809b425c81@app.fastmail.com>
On Fri, Sep 06, 2024 at 09:55:42AM +0000, Arnd Bergmann wrote:
> On Fri, Sep 6, 2024, at 09:14, Guo Ren wrote:
> > On Fri, Sep 6, 2024 at 3:18 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >> It's also unclear to me how we want this flag to interact with
> >> the existing logic in arch_get_mmap_end(), which attempts to
> >> limit the default mapping to a 47-bit address space already.
> >
> > To optimize RISC-V progress, I recommend:
> >
> > Step 1: Approve the patch.
> > Step 2: Update Go and OpenJDK's RISC-V backend to utilize it.
> > Step 3: Wait approximately several iterations for Go & OpenJDK
> > Step 4: Remove the 47-bit constraint in arch_get_mmap_end()
>
> I really want to first see a plausible explanation about why
> RISC-V can't just implement this using a 47-bit DEFAULT_MAP_WINDOW
> like all the other major architectures (x86, arm64, powerpc64),
FWIW arm64 actually limits DEFAULT_MAP_WINDOW to 48-bit in the default
configuration. We end up with a 47-bit with 16K pages but for a
different reason that has to do with LPA2 support (I doubt we need this
for the user mapping but we need to untangle some of the macros there;
that's for a separate discussion).
That said, we haven't encountered any user space problems with a 48-bit
DEFAULT_MAP_WINDOW. So I also think RISC-V should follow a similar
approach (47 or 48 bit default limit). Better to have some ABI
consistency between architectures. One can still ask for addresses above
this default limit via mmap().
--
Catalin
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
next prev parent reply other threads:[~2024-09-06 11:43 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-05 21:15 [PATCH RFC v3 0/2] mm: Introduce ADDR_LIMIT_47BIT personality flag Charlie Jenkins
2024-09-05 21:15 ` Charlie Jenkins
2024-09-05 21:15 ` [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits Charlie Jenkins
2024-09-05 21:15 ` Charlie Jenkins
2024-09-06 6:59 ` Michael Ellerman
2024-09-06 6:59 ` Michael Ellerman
2024-09-09 19:07 ` Charlie Jenkins
2024-09-09 19:07 ` Charlie Jenkins
2024-09-10 9:20 ` Christophe Leroy
2024-09-10 9:20 ` Christophe Leroy
2024-09-10 12:43 ` Geert Uytterhoeven
2024-09-10 12:43 ` Geert Uytterhoeven
2024-09-11 13:38 ` Michael Ellerman
2024-09-11 13:38 ` Michael Ellerman
2024-09-12 6:20 ` Charlie Jenkins
2024-09-12 6:20 ` Charlie Jenkins
2024-09-20 5:10 ` Michael Ellerman
2024-09-20 5:10 ` Michael Ellerman
2024-09-11 13:37 ` Michael Ellerman
2024-09-11 13:37 ` Michael Ellerman
2024-09-06 7:17 ` Arnd Bergmann
2024-09-06 7:17 ` Arnd Bergmann
2024-09-06 8:02 ` Lorenzo Stoakes
2024-09-06 8:02 ` Lorenzo Stoakes
2024-09-06 8:14 ` Lorenzo Stoakes
2024-09-06 8:14 ` Lorenzo Stoakes
2024-09-06 9:14 ` Arnd Bergmann
2024-09-06 9:14 ` Arnd Bergmann
2024-09-06 9:52 ` Lorenzo Stoakes
2024-09-06 9:52 ` Lorenzo Stoakes
2024-09-09 23:22 ` Charlie Jenkins
2024-09-09 23:22 ` Charlie Jenkins
2024-09-10 9:13 ` Arnd Bergmann
2024-09-10 9:13 ` Arnd Bergmann
2024-09-10 23:29 ` Charlie Jenkins
2024-09-10 23:29 ` Charlie Jenkins
2024-09-11 13:50 ` Michael Ellerman
2024-09-11 13:50 ` Michael Ellerman
2024-09-06 9:14 ` Guo Ren
2024-09-06 9:14 ` Guo Ren
2024-09-06 9:55 ` Arnd Bergmann
2024-09-06 9:55 ` Arnd Bergmann
2024-09-06 11:43 ` Catalin Marinas [this message]
2024-09-06 11:43 ` Catalin Marinas
2024-09-10 19:08 ` Liam R. Howlett
2024-09-10 19:08 ` Liam R. Howlett
2024-09-11 0:45 ` Charlie Jenkins
2024-09-11 0:45 ` Charlie Jenkins
2024-09-11 7:25 ` Arnd Bergmann
2024-09-11 7:25 ` Arnd Bergmann
2024-09-12 6:06 ` Charlie Jenkins
2024-09-12 6:06 ` Charlie Jenkins
2024-09-11 18:21 ` Catalin Marinas
2024-09-11 18:21 ` Catalin Marinas
2024-09-12 6:18 ` Charlie Jenkins
2024-09-12 6:18 ` Charlie Jenkins
2024-09-12 10:53 ` Catalin Marinas
2024-09-12 10:53 ` Catalin Marinas
2024-09-12 21:15 ` Charlie Jenkins
2024-09-12 21:15 ` Charlie Jenkins
2024-09-13 10:08 ` Catalin Marinas
2024-09-13 10:08 ` Catalin Marinas
2024-09-13 10:21 ` Catalin Marinas
2024-09-13 10:21 ` Catalin Marinas
2024-09-13 20:15 ` Charlie Jenkins
2024-09-13 20:15 ` Charlie Jenkins
2024-09-13 7:41 ` Lorenzo Stoakes
2024-09-13 7:41 ` Lorenzo Stoakes
2024-09-13 21:04 ` Charlie Jenkins
2024-09-13 21:04 ` Charlie Jenkins
2024-10-02 14:26 ` Palmer Dabbelt
2024-10-02 14:26 ` Palmer Dabbelt
2024-09-08 17:27 ` kernel test robot
2024-09-05 21:15 ` [PATCH RFC v3 2/2] selftests/mm: Create ADDR_LIMIT_47BIT test Charlie Jenkins
2024-09-05 21:15 ` Charlie Jenkins
2024-09-06 6:08 ` [PATCH RFC v3 0/2] mm: Introduce ADDR_LIMIT_47BIT personality flag Guo Ren
2024-09-06 6:08 ` Guo Ren
2024-09-06 6:19 ` John Paul Adrian Glaubitz
2024-09-06 6:19 ` John Paul Adrian Glaubitz
2024-09-08 11:26 ` Jiaxun Yang
2024-09-08 11:26 ` Jiaxun Yang
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=Ztrq8PBLJ3QuFJz7@arm.com \
--to=catalin.marinas@arm.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=Liam.Howlett@oracle.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=andreas@gaisler.com \
--cc=arnd@arndb.de \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=charlie@rivosinc.com \
--cc=chenhuacai@kernel.org \
--cc=chris.torek@gmail.com \
--cc=christophe.leroy@csgroup.eu \
--cc=dalias@libc.org \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=gerald.schaefer@linux.ibm.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=gor@linux.ibm.com \
--cc=guoren@kernel.org \
--cc=hca@linux.ibm.com \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=ink@jurassic.park.msu.ru \
--cc=kernel@xen0n.name \
--cc=kirill@shutemov.name \
--cc=linux-abi-devel@lists.sourceforge.net \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=lorenzo.stoakes@oracle.com \
--cc=luto@kernel.org \
--cc=mattst88@gmail.com \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=muchun.song@linux.dev \
--cc=naveen@kernel.org \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=richard.henderson@linaro.org \
--cc=shuah@kernel.org \
--cc=sparclinux@vger.kernel.org \
--cc=svens@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=tsbogend@alpha.franken.de \
--cc=vbabka@suse.cz \
--cc=vgupta@kernel.org \
--cc=x86@kernel.org \
--cc=ysato@users.sourceforge.jp \
/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.