From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Arnd Bergmann <arnd@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
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>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH 2/4] ARM: Disable HIGHPTE on PREEMPT_RT kernels
Date: Wed, 11 Dec 2024 15:55:31 +0000 [thread overview]
Message-ID: <Z1m18yn67dsJRVWA@shell.armlinux.org.uk> (raw)
In-Reply-To: <20241211140402.yf7gMExr@linutronix.de>
On Wed, Dec 11, 2024 at 03:04:02PM +0100, 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.
However, there is more to consider.
32-bit Arm works out at the same for this:
Assuming 768M of lowmem we have 196608 potential lowmem PTE
pages. Each page can map 2M of RAM in a PAE-enabled configuration,
meaning a maximum of 384G of RAM could potentially be mapped using
lowmem PTEs.
because, presumably, x86 uses 8 bytes per PTE entry, whereas on Arm we
still use 4 bytes, but because we keep two copies of a PTE (one for
hardware, the other for the kernel) it works out that we're the same
there - one PTE page can also map 2M of RAM.
However, what is quite different is the L1 page tables. On x86,
everything is nice and easy, and each page table is one 4k page.
On 32-bit Arm, this is not the case - we need to grab a 16k page for
the L1, and the more immovable allocations we have in lowmem, the
harder it will be to satisfy this. Failing to grab a 16k page
leads to fork() failing and an unusable system.
So, we want to keep as many immovable allocations out of lowmem as
possible - which is an additional constraint x86 doesn't have, and
shouldn't be overlooked without ensuring that the probability of it
happening remains acceptably low.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2024-12-11 15:55 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
2024-12-11 15:55 ` Russell King (Oracle) [this message]
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=Z1m18yn67dsJRVWA@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--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=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