linux-kernel - Re: [PATCH v3 05/10] x86: remove HIGHMEM64G support

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: <628C48B3-E6B3-4A24-A9EF-7C07F828608E@zytor.com>
Date: Thu, 27 Feb 2025 17:48:58 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: Arnd Bergmann <arnd@...nel.org>, linux-kernel@...r.kernel.org,
        x86@...nel.org, Arnd Bergmann <arnd@...db.de>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Shevchenko <andy@...nel.org>,
        Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v3 05/10] x86: remove HIGHMEM64G support

On February 27, 2025 8:51:59 AM PST, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>On Thu, 27 Feb 2025 at 07:41, H. Peter Anvin <hpa@...or.com> wrote:
>>
>> One of the generations of kernel.org ran on a dual socket system with
>> 6 GiB RAM. It was a mess; basically it achieved less than 50% memory
>> utilization because of highmem.
>
>I'll be very very happy when HIGHMEM is gone completely, but yes,
>HIGHMEM64G was particularly painful.
>
>It was definitely used, and it worked better under some loads than
>others (large user footprints with lots of anonymous memory and little
>kernel side memory pressure), but it was not great in general.
>
>I suspect that absolutely everybody who ever used it switched to
>64-bit as soon as humanly possible and nobody has likely actively used
>it for a *long* time.
>
>Good riddance,
>
>            Linus

I wish that were true. 

At rPath I had to debug a customer machine where they insisted on a 32-bit OS because they were worried about the breakage possibilities of the compat layer. In retrospect we really didn't spend enough time/effort on making sure an all-32-bit userspace would run on a 64-bit kernel; little corner cases like autofs (my fault) that only popped up when all the system software was 32 bits...