Message-Id: <4d8ee82a-b767-4c3f-9735-2a1e0f6bbc8b@app.fastmail.com>
Date: Fri, 20 Dec 2024 15:30:41 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Linus Walleij" <linus.walleij@...aro.org>,
 "David Laight" <David.Laight@...lab.com>
Cc: "Arnd Bergmann" <arnd@...nel.org>,
 "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-mm@...ck.org" <linux-mm@...ck.org>,
 "linux-rt-devel@...ts.linux.dev" <linux-rt-devel@...ts.linux.dev>,
 "Ard Biesheuvel" <ardb@...nel.org>, "Clark Williams" <clrkwllms@...nel.org>,
 "Jason Baron" <jbaron@...mai.com>, "Josh Poimboeuf" <jpoimboe@...nel.org>,
 "Mark Rutland" <mark.rutland@....com>,
 "Matthew Wilcox" <willy@...radead.org>,
 "Peter Zijlstra" <peterz@...radead.org>,
 "Russell King" <linux@...linux.org.uk>,
 "Sebastian Andrzej Siewior" <bigeasy@...utronix.de>,
 "Steven Rostedt" <rostedt@...dmis.org>
Subject: Re: [PATCH 3/4] ARM: drop CONFIG_HIGHPTE support

On Fri, Dec 20, 2024, at 14:10, Linus Walleij wrote:
> On Sat, Dec 14, 2024 at 7:41 PM David Laight <David.Laight@...lab.com> wrote:
>
>> From: Arnd Bergmann
>> > Sent: 10 December 2024 16:06
>> ...
>> > Since Arm is the last architecture remaining that uses this, and almost
>> > no 32-bit machines support more than 4GB of RAM, the cost of continuing
>> > to maintain HIGHPTE seems unjustified, so remove it here to allow
>> > simplifying the generic page table handling.
>>
>> 'Picking at nits' 'highmem' support was needed for systems with 4GB of RAM
>> in order to use more than 3GB or 3.5GB (depending on the bios) because
>> of the physical addresses that are reserved for PCI (and other MMIO).

What you mean here is CONFIG_HIGHMEM64G on x86, not CONFIG_HIGHMEM
or CONFIG_HIGHPTE.

> Wow I didn't know that, there are so many reasons why highmem is used
> by different architectures.
>
> On ARM it was originally added for a certain Marvell system with
> a mere 2GB of RAM:
> commit 053a96ca11a9785a7e63fc89eed4514a6446ec58
>
> The reason was that since the virtual address space is just 4GB and
> we have reserved virtual kernel memory from (typically) 0xc0000000
> only ~1GB can be linearly accessed by the kernel (actually less than
> that).
>
> This wasn't a problem since no ARM system was using more than
> 1GB until Nico ran into it.
>
> So the ARM "high memory" is something to do with virtual memory
> size rather than physical memory reservations as in the x86 case.

HIGHMEM works the exact same way on the major 32-bit architectures
(x86, arm, powerpc): With the default TASK_SIZE and PAGE_OFFSET
of set to 3GB (0xc0000000) you have 1GB left that is use for
the linear lowmem and the vmalloc area,  leaving between 786MB
and 900MB for lowmem, unless you shrink TASK_SIZE (CONFIG_VMSPLIT_*).

The most common systems (Intel Pentium M, PowerPC 74xx, Arm
Cortex-A9) have a 4GB address limit and have to fit both RAM and
MMIO or PCI into that, which is where the 3GB (Pentium M) through
3.9GB (i.MX6, Calxeda Highbank) total-RAM limit comes from.

The 4GB physical address limit is broken by CONFIG_PHYS_ADDR_T_64BIT
on some x86 server chipsets (Serverworks GC, HP F8, IBM Summit,
Intel 450GX, ...), Arm Cortex-A15 and PowerPC e500/e600 cores,
which gets you to the point where you fill up all your lowmem
before using all of highmem.

HIGHPTE was added when x86 servers to to 32GB, at which point
the lowmem is mostly filled with page tables for typical
workloads.

Other architectures (mips, sparc, arc, ...) have some but not
all of the above, HIGHPTE was only ever a thing on x86,
arm and frv.

     Arnd

Powered by blists - more mailing lists