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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 25ABAC54E64 for ; Mon, 25 Mar 2024 11:15:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:Cc:To:From:Date:References: In-Reply-To:Message-Id:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZGCZ+T6Qdu2fi9xiSYydXKCwACv71Nql9WQ3OFT7iQA=; b=CKcfu350iu+lmh /bWHbxQahnItAmlEUPL4z6mmnWF8TONc+o9ESg9PYX21754+5XRKlBWJrkQE7AJyjV+KsY5BRrxAb wLuN80ZZqiBpWOtFX1u5+nFIPeAXZ0NXENd9mwTJtAPBqs77Br2feBjya4/N0D2EVdphf9JLObcat aIhrYrQPMO4s/9EgIgYjTfNNAh7xPuo8cTUC7xBYIPgWx9wD8QjPoBikmZ4+GMj97uPDm7m4DFlex 7S9Wy3zwenslDY6nAXBdQTdfx5/0qFWp7tMAEGkfDCxJRS36/e/+RbVPTKg4WRm97cRAMLMgqxF8V 5hnW56rQqxYNYuJqDqaw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1roiIn-0000000Gzd1-3jES; Mon, 25 Mar 2024 11:15:41 +0000 Received: from wfhigh1-smtp.messagingengine.com ([64.147.123.152]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1roiIj-0000000GzaU-0BTw for linux-riscv@lists.infradead.org; Mon, 25 Mar 2024 11:15:39 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfhigh.west.internal (Postfix) with ESMTP id 0646718000B9; Mon, 25 Mar 2024 07:15:31 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute5.internal (MEProxy); Mon, 25 Mar 2024 07:15:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1711365331; x=1711451731; bh=z4Kn3pYXpg iAUzuK6QDRYyQRhLD9Dn62eTCOSq5cUP0=; b=OK/isPdTFrqQI/4cMYOrrqmGXY 50PVXN4faVpZIDcM+nQKPpcJsp8HKY6A9pBrXO25gQi+mYZ4l5Q4806IAHF61oe6 vYdvO37FtnvSCUNe5a/4Z1MNY7hoJeXyKtWc67mhdln7SQLItMMxArbqaU9LN4Kf BTeyDytZXE798uApFj79OBg/0EAduNeiSLTZkWADUBGZyjLKzJ1eTOSDvo761KeS iCJkRAEtxRB6m051iHakUQ5tVjstrcpLVuMHAVRuQQ7qPL6EPTmKGfFJ9x8dzq2w jI9k6qR7nfTjEml7e8cc4AjeEwpv2ffj//ESIkh7r2OALMAelwzZC0gC7dKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1711365331; x=1711451731; bh=z4Kn3pYXpgiAUzuK6QDRYyQRhLD9 Dn62eTCOSq5cUP0=; b=qv+awkv1sbrET62JITAJj90ptP70MGbPz7R3Gjx4kMkc cl2bPh7jZ8YuPY3qLCzYTTX/TzqNJjKeAP+eEBHzGfomJd6PcC0dLfEUUlaxui8l gTK14QDH8bkmPJ7yk+LuZ8gRtpuX+8XnRBjI5AxvEJcIXJvrLvWfBVl1ZEUITyT5 /UmJ3BDZQHoNWi/WWcv9visDEDgFXxghMrfBH791hSWJlKGIFrEMci+d8/rNPb/P Td6RUt9NUsKD4sKU8ybS8GiKybSzzr2K0pMKfMnbQ1Z+alinCTYDcTA/3Hh8BEhN F4ruMTa6bkaZvYLcf+c7FIOkUb9gedPC+Buh2OTrVg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddutddgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrth htvghrnhepffehueegteeihfegtefhjefgtdeugfegjeelheejueethfefgeeghfektdek teffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8969FB6008D; Mon, 25 Mar 2024 07:15:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-332-gdeb4194079-fm-20240319.002-gdeb41940 MIME-Version: 1.0 Message-Id: In-Reply-To: <1883cf6b-7756-405b-a843-d8ae31e01d61@ghiti.fr> References: <20240313180010.295747-1-samuel.holland@sifive.com> <88de4a1a-047e-4be9-b5b0-3e53434dc022@sifive.com> <1883cf6b-7756-405b-a843-d8ae31e01d61@ghiti.fr> Date: Mon, 25 Mar 2024 12:15:10 +0100 From: "Arnd Bergmann" To: "Alexandre Ghiti" , "Samuel Holland" , "Alexandre Ghiti" Cc: "Palmer Dabbelt" , linux-riscv@lists.infradead.org, "Albert Ou" , "Andrew Morton" , "Charlie Jenkins" , guoren , "Jisheng Zhang" , "Kemeng Shi" , "Matthew Wilcox" , "Mike Rapoport" , "Paul Walmsley" , "Xiao W Wang" , "Yangyu Chen" , linux-kernel@vger.kernel.org Subject: Re: [PATCH] riscv: Define TASK_SIZE_MAX for __access_ok() X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240325_041537_320576_11A2306D X-CRM114-Status: GOOD ( 21.32 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Mon, Mar 25, 2024, at 08:25, Alexandre Ghiti wrote: > On 24/03/2024 23:05, Arnd Bergmann wrote: >> On Tue, Mar 19, 2024, at 17:51, Alexandre Ghiti wrote: >>> >>> The use of alternatives allows to return right away if the buffer is >>> beyond the usable user address space, and it's not just "slightly >>> faster" for some cases (a very large buffer with only a few bytes being >>> beyond the limit or someone could fault-in all the user pages and fail >>> very late...etc). access_ok() is here to guarantee that such situations >>> don't happen, so actually it makes more sense to use an alternative to >>> avoid that. >> The access_ok() function really wants a compile-time constant >> value for TASK_SIZE_MAX so it can do constant folding for >> repeated calls inside of one function, so for configurations >> with a boot-time selected TASK_SIZE_64 it's already not ideal, >> with or without alternatives. >> >> If I read the current code correctly, riscv doesn't even >> have a way to build with a compile-time selected >> VA_BITS/PGDIR_SIZE, which is probably a better place to >> start optimizing, since this rarely needs to be selected >> dynamically. > > > Indeed, we do not support compile-time fixed VA_BITS! We could, but that > would only be used for custom kernels. I don't think distro kernels will > ever (?) propose 3 different kernels for sv39, sv48 and sv57 because the > cost of dynamically choosing the address space width is not big enough > to me (and the burden of maintaining 3 different kernels is). > > Let me know if I'm wrong, I'd be happy to work on that. My feeling is that in most cases, users are better off with a compile-time default, given that the addressable memory has a factor of 512 between each step. With sv39, I think you are limited to having all RAM in the first 128GB of physical address space, and each process is limited to 256GB virtual addressing, but this is already covers pretty much anything you want to do on small systems that run a custom kernel. On most desktop/server/cloud distros, hardwiring sv48 is probably sufficient if all general purpose machines support this, and it should be enough even for commercial databases that micro-optimize 100TB datasets through a permanent mmap(), as well as most NUMA systems with discontiguous memory. This adds a little cost over hardcoded sv39, but is still faster than a boot-time sv39/sv48 config that most users will not be aware of. Once enterprise distros certify systems beyond a few dozen TB of RAM, they probably need to enable the boot time detection, until then I think the few users with gigantic systems will probably be fine running a custom sv57 kernel. At that point, that distro can start shipping a kernel with boot-time detected page table sizes. Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv