linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
	"Arnd Bergmann" <arnd@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-rt-devel@lists.linux.dev,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Clark Williams" <clrkwllms@kernel.org>,
	"Jason Baron" <jbaron@akamai.com>,
	"Josh Poimboeuf" <jpoimboe@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Russell King" <linux@armlinux.org.uk>,
	"Steven Rostedt" <rostedt@goodmis.org>
Subject: Re: [PATCH 2/4] ARM: Disable HIGHPTE on PREEMPT_RT kernels
Date: Wed, 11 Dec 2024 15:30:22 +0100	[thread overview]
Message-ID: <001c1d0e-a0fd-47f4-be35-0fd808f3b01a@app.fastmail.com> (raw)
In-Reply-To: <20241211140402.yf7gMExr@linutronix.de>

On Wed, Dec 11, 2024, at 15:04, Sebastian Andrzej Siewior wrote:
> On 2024-12-11 14:48:11 [+0100], To Arnd Bergmann wrote:
>> I guess if you have boxes with 4GiB+ and can proof that the performance
>> improves without HIGHPTE (since you don't have to map the page table).
>> The question is then how much of low mem has to be used instead and when
>> does it start to hurt.
>
> Some numbers have been been documented in commit
>    14315592009c1 ("x86, mm: Allow highmem user page tables to be 
> disabled at boot time")
>
> and I would like cite:
> | We could probably handwave up an argument for a threshold at 16G of total
> | RAM.
>
> which means HIGHPTE would make sense with >= 16GiB of memory.

Very useful, thanks!

On x86, that means we can definitely remove HIGHPTE along with
CONFIG_HIGHMEM64G on x86.

On 32-bit ARM, we still need to support LPAE for systems that
require 64-bit addressing. LPAE supports 36 bits of addressing
(up to 64GB), but the largest actual size I've seen mentioned
is 16GB (Hisilicon HiP04, Calxeda Midway servers) and I'm
certain nobody actually requires these to perform well
given that they are no longer useful for the workloads they
were designed for.

There are also a small number of embedded systems with 8GB
(Ti Keystone2, NVidia Tegra3, Marvell Armada XP), but they
are rare enough that turning off HIGHPTE is completely safe.

      Arnd


  reply	other threads:[~2024-12-11 14:30 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-10 16:05 [PATCH 0/4] ARM: towards 32-bit preempt-rt support Arnd Bergmann
2024-12-10 16:05 ` [PATCH 1/4] ARM: Disable jump-label on PREEMPT_RT Arnd Bergmann
2024-12-11 13:04   ` Linus Walleij
2024-12-11 13:26   ` Sebastian Andrzej Siewior
2024-12-10 16:05 ` [PATCH 2/4] ARM: Disable HIGHPTE on PREEMPT_RT kernels Arnd Bergmann
2024-12-11 13:29   ` Linus Walleij
2024-12-11 15:22     ` Sebastian Andrzej Siewior
2024-12-13  0:27       ` Linus Walleij
2024-12-13  9:11         ` Russell King (Oracle)
2024-12-14 22:11           ` Matthew Wilcox
2024-12-11 13:48   ` Sebastian Andrzej Siewior
2024-12-11 14:04     ` Sebastian Andrzej Siewior
2024-12-11 14:30       ` Arnd Bergmann [this message]
2024-12-11 15:55       ` Russell King (Oracle)
2024-12-20 14:37         ` Arnd Bergmann
2024-12-10 16:05 ` [PATCH 3/4] ARM: drop CONFIG_HIGHPTE support Arnd Bergmann
2024-12-11 13:32   ` Linus Walleij
2024-12-11 13:50     ` Russell King (Oracle)
2024-12-11 14:31       ` Linus Walleij
2024-12-11 14:25   ` Sebastian Andrzej Siewior
2024-12-14 18:40   ` David Laight
2024-12-20 13:10     ` Linus Walleij
2024-12-20 14:30       ` Arnd Bergmann
2024-12-10 16:05 ` [PATCH 4/4] mm: drop HIGHPTE support altogether Arnd Bergmann
2024-12-11 13:53   ` Linus Walleij
2024-12-11 14:29   ` Sebastian Andrzej Siewior

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=001c1d0e-a0fd-47f4-be35-0fd808f3b01a@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=ardb@kernel.org \
    --cc=arnd@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=clrkwllms@kernel.org \
    --cc=jbaron@akamai.com \
    --cc=jpoimboe@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --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