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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 79041C77B7F for ; Fri, 12 May 2023 03:39:21 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4QHZJ75dW1z3fZM for ; Fri, 12 May 2023 13:39:19 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=U4rplEw0; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=2604:1380:4641:c500::1; helo=dfw.source.kernel.org; envelope-from=rppt@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=U4rplEw0; dkim-atps=neutral Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4QHZHB38mDz3cFw for ; Fri, 12 May 2023 13:38:30 +1000 (AEST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9A6A964D9A; Fri, 12 May 2023 03:38:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15A0DC433EF; Fri, 12 May 2023 03:38:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683862707; bh=Q7pZ6HkRh3PVDzBCV74mB+fwpBcm2L4Wrr7Gj6KO6ZA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=U4rplEw0qMOGxowZ1loQ7IR10mVPR+gkIHrN9H2/CYQigVdydLPavay7G++a7nk75 jDhpGXpsFo8grDqyj+dAD0bRHJYnhZ3zC9JzvBPFC3B2RpUt1tYfAWrn3pIHyEvUc0 m+plA03PmuYT+NcYOD6DwNQyNX3nG8GNV7/Tz7bjzisl+mJN6FAg46r36holy/6HO4 6GEsQAkOKAoidlLLVYOcRtmzSHojiofTEI1BfDjbKkAJM3vujpQ7oWR4AovPMspdwk AfdZmFHnb8dcLpWYTKW3v5BTK8ry629pZRiCq4rIBS69MISbPUUJXyByuj5gGgwTNw bDNRPX9IyrHYA== Date: Thu, 11 May 2023 20:38:24 -0700 From: Mike Rapoport To: Matthew Wilcox Subject: Re: [PATCH 00/23] arch: allow pte_offset_map[_lock]() to fail Message-ID: <20230512033824.GF4135@kernel.org> References: <77a5d8c-406b-7068-4f17-23b7ac53bc83@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Michel Lespinasse , linux-ia64@vger.kernel.org, David Hildenbrand , Peter Zijlstra , Catalin Marinas , Qi Zheng , linux-kernel@vger.kernel.org, Max Filippov , sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org, Claudio Imbrenda , Will Deacon , Greg Ungerer , linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, Helge Deller , x86@kernel.org, Hugh Dickins , Russell King , Geert Uytterhoeven , Christian Borntraeger , Alexandre Ghiti , Heiko Carstens , linux-m68k@lists.linux-m68k.org, John Paul Adrian Glaubitz , John David Anglin , Suren Baghdasaryan , linux-arm-ke rnel@lists.infradead.org, Chris Zankel , Michal Simek , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, linux-mm@kvack.org, linux-mips@vger.kernel.org, Palmer Dabbelt , "Aneesh Kumar K.V" , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" , "Kirill A. Shutemov" , Mike Kravetz Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi, On Thu, May 11, 2023 at 03:02:55PM +0100, Matthew Wilcox wrote: > On Wed, May 10, 2023 at 09:35:44PM -0700, Hugh Dickins wrote: > > On Wed, 10 May 2023, Matthew Wilcox wrote: > > > > I don't really understand why you're going down a remove-CONFIG_HIGHPTE > > route: I thought you were motivated by the awkardness of kmap on large > > folios; but I don't see how removing HIGHPTE helps with that at all > > (unless you have a "large page tables" effort in mind, but I doubt it). > > Quite right, my primary concern is filesystem metadata; primarily > directories as I don't think anybody has ever supported symlinks or > superblocks larger than 4kB. > > I was thinking that removing CONFIG_HIGHPTE might simplify the page > fault handling path a little, but now I've looked at it some more, and > I'm not sure there's any simplification to be had. It should probably > use kmap_local instead of kmap_atomic(), though. Removing CONFIG_HIGHPTE will drop several lines and will allow to get rid of custom __pte_alloc_one on x86. -- Sincerely yours, Mike.