Message-Id: <4fcd272f-81e3-4729-922b-588ad144e39b@app.fastmail.com>
Date: Fri, 12 Sep 2025 12:30:59 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Richard Weinberger" <richard@....at>, "Dave Hansen" <dave@...1.net>
Cc: ksummit <ksummit@...ts.linux.dev>,
 linux-kernel <linux-kernel@...r.kernel.org>,
 linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
 linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
 linux-mips <linux-mips@...r.kernel.org>, linux-mm <linux-mm@...ck.org>,
 imx <imx@...ts.linux.dev>,
 "Christophe Leroy" <christophe.leroy@...roup.eu>,
 "Lucas Stach" <l.stach@...gutronix.de>,
 "Linus Walleij" <linus.walleij@...aro.org>,
 "Geert Uytterhoeven" <geert+renesas@...der.be>,
 "Ankur Arora" <ankur.a.arora@...cle.com>,
 "David Hildenbrand" <david@...hat.com>,
 "Mike Rapoport" <rppt@...nel.org>,
 "Lorenzo Stoakes" <lorenzo.stoakes@...cle.com>,
 "Matthew Wilcox" <willy@...radead.org>,
 "Andrew Morton" <akpm@...ux-foundation.org>,
 "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 "Vlastimil Babka" <vbabka@...e.cz>,
 "Suren Baghdasaryan" <surenb@...gle.com>,
 "Ira Weiny" <ira.weiny@...el.com>, "Nishanth Menon" <nm@...com>,
 Heiko Stübner <heiko@...ech.de>,
 "Alexander Sverdlin" <alexander.sverdlin@...il.com>,
 "Chester A. Unal" <chester.a.unal@...nc9.com>,
 "Sergio Paracuellos" <sergio.paracuellos@...il.com>,
 "Andreas Larsson" <andreas@...sler.com>
Subject: Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

On Wed, Sep 10, 2025, at 22:33, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Dave Hansen" <dave@...1.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

Powered by blists - more mailing lists