From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 113B4E7717D for ; Wed, 11 Dec 2024 15:55:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D8B56B0092; Wed, 11 Dec 2024 10:55:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9872B6B0093; Wed, 11 Dec 2024 10:55:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 84F6D6B0095; Wed, 11 Dec 2024 10:55:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 62B396B0092 for ; Wed, 11 Dec 2024 10:55:52 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1C6A21A1291 for ; Wed, 11 Dec 2024 15:55:52 +0000 (UTC) X-FDA: 82883128692.14.5EE9FF4 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) by imf09.hostedemail.com (Postfix) with ESMTP id BF99F140014 for ; Wed, 11 Dec 2024 15:55:33 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=ulUOh6HO; dmarc=pass (policy=none) header.from=armlinux.org.uk; spf=none (imf09.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733932528; a=rsa-sha256; cv=none; b=7qr6WGBJ88rOwNHTH1Xl8S3ckvbGE5xHYyjq+Egk77WN70Rtc5RFLTqDmGwFOb9D4BeuD1 XIZaIiAWStlCx/jq4R/WTN7P941HN3RINsVP+r1NQiMHLEtcCQQZWGiVtLq2bFt7gJdroh o/f1cedJp/x+rXGbFZB2kwW5wct2S/c= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=ulUOh6HO; dmarc=pass (policy=none) header.from=armlinux.org.uk; spf=none (imf09.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733932528; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=nNWhv5561LH+95ZybovZ5QdJpH0cPUFUZxKRgUtXR3E=; b=S6x2LL0YVlbRFEfPgXD49B/po7GbYqf4BwDc46rXbsnAdJLmd6+rH1mhdcNg1uPaDRhknY FxkdfaUNqxeREiYMw4t1yYWESFCZaTuguSHsvQNo/ahRLAyF7eB1w0eETlTJEvSqi1dqWz j1w84PQRGVxkCmSpx0Cn0+vc8O7FKbI= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nNWhv5561LH+95ZybovZ5QdJpH0cPUFUZxKRgUtXR3E=; b=ulUOh6HOqEKJ/+/0ZTK/7V4JHs IYfIm3L3Fkn9lb8DFP5UyS6eX3eSLbEgzX29gw5Me/d9xkMQ//Hn+bJbR3pT4jN4rErOXi4eKbQGp +OL+TBvpdG0l8l54bTeNZTfTEWl3xU5wsNCqV5TyfESZ5fsf+soeB60fmIsNqlJ4tbD1/59jcMOnH SBoNQaErwL41M+p5wwp9jRoe3pWupX74UV5NihoTveX9a8DSi484J4WXGHkXi9QEvGeMz9AT0w79t FFAyGZ3nPdkV4s5LaWpBgIO4/oM9EO+F2DWiUnOMCtOt5as48fE1m8hqzLQxacQ758xMBbNzsjrcd L3MGkrlA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:47116) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tLP3o-000493-1m; Wed, 11 Dec 2024 15:55:36 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.96) (envelope-from ) id 1tLP3j-0004Rn-1O; Wed, 11 Dec 2024 15:55:31 +0000 Date: Wed, 11 Dec 2024 15:55:31 +0000 From: "Russell King (Oracle)" To: Sebastian Andrzej Siewior Cc: Arnd Bergmann , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Arnd Bergmann , linux-mm@kvack.org, linux-rt-devel@lists.linux.dev, Ard Biesheuvel , Clark Williams , Jason Baron , Josh Poimboeuf , Linus Walleij , Mark Rutland , Matthew Wilcox , Peter Zijlstra , Steven Rostedt Subject: Re: [PATCH 2/4] ARM: Disable HIGHPTE on PREEMPT_RT kernels Message-ID: References: <20241210160556.2341497-1-arnd@kernel.org> <20241210160556.2341497-3-arnd@kernel.org> <20241211134811.wM_UADhQ@linutronix.de> <20241211140402.yf7gMExr@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241211140402.yf7gMExr@linutronix.de> X-Stat-Signature: zxwm8zeauoox7wawdrjegxka6zafwjjz X-Rspam-User: X-Rspamd-Queue-Id: BF99F140014 X-Rspamd-Server: rspam08 X-HE-Tag: 1733932533-20718 X-HE-Meta: U2FsdGVkX1/mvmkQY4gnvkOrWRSpmiEtYJEtW1cnRkNzEn+IQCfvm68eYz+Dw6t7PFlRCmfh9oGSZ5M5Wp5A8f42BJldbCNpy+emsZtB3W5hi2sGOdpGvL5cAXHX0bYs0tGZyE4iSL/bJZ/nE9xlqLEvLYsguaHZzaalSntF5Rhm1B9FDQ82DDbZY10fm11vM9nS/WcE0mifk0AUcSD/h4fMbK8xBIRP9okaMb/91EFSU7GU3kRYUWEvPkVWmO6jAh1W19bbPHI4oIyrt13Inu4gbeVe61y7Rm6/aUBpTL65IJ3v42IKLZAzTY0kdlMCZdMAq5tzR+8y9Jw1YjVSeEPw4uT8+W/DY/ZJt801xjGnHl+9ksHriRSPP797aG0xvSKPvZ1oluvKq+383Q7jEy+3ZQuyYFRAaMYr4nQb3eMNbQHuW3RiGSGW0GAXj15mrna7S0t99Rb6dXa85N2a1zRE01q5/Xzf3K9AZbzEBIfvpvmJ28EBBJ3CV7cDPb6lWzteR1s2Ez3DewYFxoRvjHwUcpQHlM8Fl3p6DE9fsiw4Ft/dNL9Nkd7H2wKnYDzsIL8v1P2Kjno8yqQL1zSZLvWSK7kqxwgHJEOOOAL9dKS43bXZobnXqLUX3qaaAL9SInxmzjZlKXgFVUNld6Qt3HNR0oqVSKEpHmQSxyr0Jr4JpnplmsR6r568OqA2xFsbL+I+KEaZJuqt4gOSPBuHARK1aqPi0zacBWDWz2Y9jURN0Vw0lJZRFJDJvM410uNORNdAvg4+Trxp0k+VSC6ffoOMcXd/pKWxRyDCITeZmq0KTZOVz5u4Ovq1CV5yEGHgQE3zIN0yuA0LUagZ4C9vq5NVwRUcZB/rEzCk/QFrcs5yDlI6hsQR/0E90sxWATfI2JppJ9X0d/z9vIcytsuObkbaJLr1Pi4cvnFlFyqu3UR/YxTwbAvTA4h9U+N0oaY7cztfxqKNW/Qb0OubMQT pOK8h3DH 1cP2uadVjd8ockOdLp4R7i9umuCi6Wm6gwAxUNUrEO2BNmtjifWIq4bBZNRBGR5WbnLFaocwxLynyUUafiaCy0enbpoMp0QCVxG/ziFx254SOHm2wO+XlOq3wPUHeVwAob5jq3ueHKDgF5/cVseJkrQ6fFGdn8M6gB/CfL8ls79AIiBe/VHJNZobBCC1YL4A1EcKqLWs24Yl/UTUzEVzRCN7eXMEZqbDkPkMzRCQD/wLG7Zyje4R4VySK5ztlRSJkxcan+Y0QZmP3ttZDlGP4ako/aT7uexAEl5r9qKhFwH8cC46aNj2k1Bc4iA+KxCnWPzScBK+F4s4auM8WvKQ/STAeLKCQ+N14ABdH8egDscUncMfSLY5XQUSM3FqWDkN3xxl8DBmiFsSDz+XiSYxjEWZdseC+G6Wwtq35Rcvh3UCW1l/9lC5ARSYSCtLK0gres2cjW2DRmLmewSVRGMCYhHwCH9OD7u5xmlyRlvuCfbWhEwaciKKjMeL3mw/AO/xf8PO0qE4H7cX2/+p3DRbKAsioUg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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!