From: "Arnd Bergmann" <arnd@arndb.de>
To: "Richard Weinberger" <richard@nod.at>, "Dave Hansen" <dave@sr71.net>
Cc: ksummit <ksummit@lists.linux.dev>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-mips <linux-mips@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>, imx <imx@lists.linux.dev>,
"Christophe Leroy" <christophe.leroy@csgroup.eu>,
"Lucas Stach" <l.stach@pengutronix.de>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Ankur Arora" <ankur.a.arora@oracle.com>,
"David Hildenbrand" <david@redhat.com>,
"Mike Rapoport" <rppt@kernel.org>,
"Lorenzo Stoakes" <lorenzo.stoakes@oracle.com>,
"Matthew Wilcox" <willy@infradead.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
"Vlastimil Babka" <vbabka@suse.cz>,
"Suren Baghdasaryan" <surenb@google.com>,
"Ira Weiny" <ira.weiny@intel.com>, "Nishanth Menon" <nm@ti.com>,
"Heiko Stübner" <heiko@sntech.de>,
"Alexander Sverdlin" <alexander.sverdlin@gmail.com>,
"Chester A. Unal" <chester.a.unal@arinc9.com>,
"Sergio Paracuellos" <sergio.paracuellos@gmail.com>,
"Andreas Larsson" <andreas@gaisler.com>
Subject: Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout
Date: Fri, 12 Sep 2025 12:30:59 +0200 [thread overview]
Message-ID: <4fcd272f-81e3-4729-922b-588ad144e39b@app.fastmail.com> (raw)
In-Reply-To: <640041197.22387.1757536385810.JavaMail.zimbra@nod.at>
On Wed, Sep 10, 2025, at 22:33, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Dave Hansen" <dave@sr71.net>
>>> Even with a new memory split, which could utilize most of the
>>> available memory, I expect there to be issues with various
>>> applications and FPGA device drivers.
I also remember driver problems on older Marvell NAS systems, which
we never fully figured out, my best guess in retrospect is that these
had devices with DMA address restrictions, and if lowmem is small
enough it would always work, but any lowmem allocation above the
hardware DMA address limit would cause data corruption.
A similar restriction exists on Raspberry Pi, which can run
both 32-bit and 64-bit kernels. The workaround in this case is
a combination of:
- correctly representing the DMA limits in the devicetree, using
the 'dma-ranges' property.
- enabling SWIOTLB (which is not enabled by default on 32-bit
Arm without LPAE).
- Using GFP_DMA or dma_alloc_noncoherent() allocations for
streaming buffers if possible, to avoid extra bounces
(documenting this here, in case someone tries out VMSPLIT_2G
and runs into a similar bug on other hardware, I expect there
may be a few more of these, though most hardware should be fine)
>> I'd be really curious what the _actual_ issues would be with a
>> non-standard split. There are a lot of "maybe" problems and solutions
>> here, but it's hard to move forward without known practical problems to
>> tackle.
>>
>> Has anybody run into actual end user visible problems when using one of
>> weirdo PAGE_OFFSET configs?
>
> In the past I saw that programs such as the Java Runtime (JRE) ran into
> address space limitations due to a 2G/2G split on embedded systems.
> Reverting to a 3G/1G split fixed the problems.
Right, that makes sense, given the tricks they likely play on the
virtual address space. Are the 2GB devices you maintain using a JRE,
or was this on other embedded hardware? How common is Java still in
this type of workload?
Another type of software that I've seen mentioned struggling with
VMSPLIT_2G is web browsers, but I don't know if that is a similar
problem with a V8/spidermonkey JIT managing its own address space,
or more about general bloat exceeding 2GB of user addresses.
Arnd
next prev parent reply other threads:[~2025-09-12 10:31 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 21:23 Arnd Bergmann
2025-09-09 21:38 ` H. Peter Anvin
2025-09-09 22:24 ` Linus Torvalds
2025-09-09 22:39 ` H. Peter Anvin
2025-09-10 1:06 ` René Herman
2025-09-10 1:46 ` Matthew Wilcox
2025-09-10 9:49 ` Linus Walleij
2025-09-10 12:17 ` Arnd Bergmann
2025-09-10 12:32 ` David Hildenbrand
2025-09-10 13:10 ` Linus Walleij
2025-09-10 14:04 ` Matthew Wilcox
2025-09-10 15:13 ` Arnd Bergmann
2025-09-10 14:04 ` Richard Weinberger
2025-09-10 16:34 ` Dave Hansen
2025-09-10 20:33 ` Richard Weinberger
2025-09-10 21:56 ` René Herman
2025-09-12 10:30 ` Arnd Bergmann [this message]
2025-09-12 12:46 ` Linus Walleij
2025-10-06 20:15 ` Richard Weinberger
2025-09-10 17:11 ` Christophe Leroy
2025-09-10 19:37 ` Richard Weinberger
2025-09-11 5:38 ` Andreas Larsson
2025-09-11 7:53 ` Arnd Bergmann
2025-09-12 9:32 ` Andreas Larsson
2025-09-12 9:36 ` H. Peter Anvin
2025-09-12 10:17 ` Arnd Bergmann
2025-09-12 9:58 ` H. Peter Anvin
2025-09-12 13:16 ` Matthew Wilcox
2025-09-12 16:49 ` Nicolas Ferre
2025-09-12 21:09 ` Arnd Bergmann
2025-09-17 12:59 ` Jason Gunthorpe
2025-09-18 13:12 ` Arnd Bergmann
2025-09-18 13:34 ` Andrew Lunn
2025-09-18 16:18 ` Arnd Bergmann
2025-09-18 16:32 ` Andrew Lunn
2025-09-19 7:17 ` Geert Uytterhoeven
2025-09-19 14:22 ` Arnd Bergmann
2025-09-19 14:34 ` Jason Gunthorpe
2025-09-22 6:58 ` Arnd Bergmann
2025-09-22 17:05 ` Nicolas Schichan
2025-09-22 21:22 ` Arnd Bergmann
2025-09-19 14:41 ` Nicolas Ferre
2025-09-19 14:22 ` Nicolas Ferre
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=4fcd272f-81e3-4729-922b-588ad144e39b@app.fastmail.com \
--to=arnd@arndb.de \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.sverdlin@gmail.com \
--cc=andreas@gaisler.com \
--cc=ankur.a.arora@oracle.com \
--cc=chester.a.unal@arinc9.com \
--cc=christophe.leroy@csgroup.eu \
--cc=dave@sr71.net \
--cc=david@redhat.com \
--cc=geert+renesas@glider.be \
--cc=heiko@sntech.de \
--cc=imx@lists.linux.dev \
--cc=ira.weiny@intel.com \
--cc=ksummit@lists.linux.dev \
--cc=l.stach@pengutronix.de \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=nm@ti.com \
--cc=richard@nod.at \
--cc=rppt@kernel.org \
--cc=sergio.paracuellos@gmail.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--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