linux-kernel - Re: 32-bit HIGHMEM and game console downstreams

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <11e667d6-2210-47f0-a9ec-a134a60e138c@heyquark.com>
Date: Tue, 16 Sep 2025 11:57:00 +1000
From: Ash Logan <ash@...quark.com>
To: Arnd Bergmann <arnd@...db.de>,
 Christophe Leroy <christophe.leroy@...roup.eu>
Cc: "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 officialTechflashYT@...il.com, "A. Wilcox" <AWilcox@...cox-tech.com>,
 Michael Ellerman <mpe@...erman.id.au>
Subject: Re: 32-bit HIGHMEM and game console downstreams

On 13/9/25 23:52, Arnd Bergmann wrote:

Hi Arnd! Thanks for your reply.

> Like most other machines, this one is probably fine with a combination
> of a custom LOWMEM_SIZE setting and using zram-highmem, even if we
> end up removing support for highmem page cache.

Good shout - I'm now testing a 2G/2G split which allows for 1536MiB 
lowmem. I know that's a somewhat aggressive setting for userspace, so 
we'll see if anything breaks. I read Rasbian shipped similar kernels and 
had issues with Wine, though that's not a common use case on PowerPC ^^

> The smaller devices are probable getting problematic sooner, 96MB
> in the Wii is already really tight and this only gets worse over
> time.

The maintainer of that downstream claims to be able to boot modern 
text-mode distros on the GameCube' 24MB, which I find really impressive!

> Just to be clear: there is no general 32-bit deprecation going on. When
> I talked about phasing out 32-bit platforms over time, that is purely
> going to be those that have no users left, or the few ones that are
> causing more work than they are worth. E.g. The ppc405 ones got
> removed recently (after many years of discussion) because they were
> making ppc440 maintenance harder and had no known users.
> 
> Highmem does get in the way, but unless more -mm folks make a strong
> argument in favor of removing it all, it's more likely that we'll
> go with Willy's suggestion of keeping highmem on page cache (anon
> and file mappings) than just keeling zram, and even that would
> still work.

That's good to hear. I would like to have the page cache, though I'm 
still going to try and maximise lowmem as well.

Thanks,
Ash