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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DBD6EEE49AB for ; Tue, 22 Aug 2023 18:46:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229517AbjHVSq6 (ORCPT ); Tue, 22 Aug 2023 14:46:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229798AbjHVSq5 (ORCPT ); Tue, 22 Aug 2023 14:46:57 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0DED810B; Tue, 22 Aug 2023 11:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=J31tX1IjpfiCQxayR49GQoOflBRKi40HTvUBqvNFOZY=; b=RAzY/3FmhkOeez9WRyFLLv4ZSq U9rG0oMX7UlPyR/D8x7L4mEEOPnVmJVv72dkSFxz3K3fx+HJjz0yoyeOk1QTD4Bln2OjioJ+WG3UG CnjPXzmOixxB/77VgttDEjTQVN+QS8gKeI40gmVskiO5EQQ7Den2j/G96cP6WVrEfYYyC+vujh8og eJ/TUp3RaxHtDOKFUHYAODkAttL76BNxIck57m/l5uS1N1aQ2ZPhNzqFsS9g+ZZtgp8Bjfnnp5VzH Sh7M7AqyItqQzyxp6n+/g33j9JDbH/tinn2kkkuSh0EOjzNT3lsO7aLfQFQIinDdpU3s/xpPYqKx1 u14eK8IA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qYWNp-000KO8-5r; Tue, 22 Aug 2023 18:45:41 +0000 Date: Tue, 22 Aug 2023 19:45:41 +0100 From: Matthew Wilcox To: Hugh Dickins Cc: Peter Xu , Jann Horn , Andrew Morton , Mike Kravetz , Mike Rapoport , "Kirill A. Shutemov" , David Hildenbrand , Suren Baghdasaryan , Qi Zheng , Yang Shi , Mel Gorman , Peter Zijlstra , Will Deacon , Yu Zhao , Alistair Popple , Ralph Campbell , Ira Weiny , Steven Price , SeongJae Park , Lorenzo Stoakes , Huang Ying , Naoya Horiguchi , Christophe Leroy , Zack Rusin , Jason Gunthorpe , Axel Rasmussen , Anshuman Khandual , Pasha Tatashin , Miaohe Lin , Minchan Kim , Christoph Hellwig , Song Liu , Thomas Hellstrom , Russell King , "David S. Miller" , Michael Ellerman , "Aneesh Kumar K.V" , Heiko Carstens , Christian Borntraeger , Claudio Imbrenda , Alexander Gordeev , Gerald Schaefer , Vasily Gorbik , Vishal Moola , Vlastimil Babka , Zi Yan , Zach O'Keefe , Linux ARM , sparclinux@vger.kernel.org, linuxppc-dev , linux-s390 , kernel list , Linux-MM Subject: Re: [PATCH mm-unstable] mm/khugepaged: fix collapse_pte_mapped_thp() versus uffd Message-ID: References: <4d31abf5-56c0-9f3d-d12f-c9317936691@google.com> <1b7c7056-d742-86bf-fec-fdb024b2381@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1b7c7056-d742-86bf-fec-fdb024b2381@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-s390@vger.kernel.org On Tue, Aug 22, 2023 at 11:34:19AM -0700, Hugh Dickins wrote: > (Yes, the locking is a bit confusing: but mainly for the unrelated reason, > that with the split locking configs, we never quite know whether this lock > is the same as that lock or not, and so have to be rather careful.) Is it time to remove the PTE split locking config option? I believe all supported architectures have at least two levels of page tables, so if we have split ptlocks, ptl and pml are always different from each other (it's just that on two level machines, pmd == pud == p4d == pgd). With huge thread counts now being the norm, it's hard to see why anybody would want to support SMP and !SPLIT_PTE_PTLOCKS. To quote the documentation ... Split page table lock for PTE tables is enabled compile-time if CONFIG_SPLIT_PTLOCK_CPUS (usually 4) is less or equal to NR_CPUS. If split lock is disabled, all tables are guarded by mm->page_table_lock. You can barely buy a wrist-watch without eight CPUs these days. 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 EA177EE49AB for ; Tue, 22 Aug 2023 18:47:52 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256 header.s=casper.20170209 header.b=RAzY/3Fm; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4RVddM1Lgnz3c3g for ; Wed, 23 Aug 2023 04:47:51 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256 header.s=casper.20170209 header.b=RAzY/3Fm; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=infradead.org (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org; envelope-from=willy@infradead.org; receiver=lists.ozlabs.org) Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4RVdcM4FSqz2xpx for ; Wed, 23 Aug 2023 04:46:59 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=J31tX1IjpfiCQxayR49GQoOflBRKi40HTvUBqvNFOZY=; b=RAzY/3FmhkOeez9WRyFLLv4ZSq U9rG0oMX7UlPyR/D8x7L4mEEOPnVmJVv72dkSFxz3K3fx+HJjz0yoyeOk1QTD4Bln2OjioJ+WG3UG CnjPXzmOixxB/77VgttDEjTQVN+QS8gKeI40gmVskiO5EQQ7Den2j/G96cP6WVrEfYYyC+vujh8og eJ/TUp3RaxHtDOKFUHYAODkAttL76BNxIck57m/l5uS1N1aQ2ZPhNzqFsS9g+ZZtgp8Bjfnnp5VzH Sh7M7AqyItqQzyxp6n+/g33j9JDbH/tinn2kkkuSh0EOjzNT3lsO7aLfQFQIinDdpU3s/xpPYqKx1 u14eK8IA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qYWNp-000KO8-5r; Tue, 22 Aug 2023 18:45:41 +0000 Date: Tue, 22 Aug 2023 19:45:41 +0100 From: Matthew Wilcox To: Hugh Dickins Subject: Re: [PATCH mm-unstable] mm/khugepaged: fix collapse_pte_mapped_thp() versus uffd Message-ID: References: <4d31abf5-56c0-9f3d-d12f-c9317936691@google.com> <1b7c7056-d742-86bf-fec-fdb024b2381@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1b7c7056-d742-86bf-fec-fdb024b2381@google.com> 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: Miaohe Lin , Anshuman Khandual , David Hildenbrand , Peter Zijlstra , Yang Shi , Peter Xu , kernel list , Song Liu , sparclinux@vger.kernel.org, Alexander Gordeev , Claudio Imbrenda , Will Deacon , linux-s390 , Yu Zhao , Ira Weiny , Alistair Popple , Russell King , Steven Price , Christoph Hellwig , Jason Gunthorpe , "Aneesh Kumar K.V" , Zi Yan , Huang Ying , Axel Rasmussen , Gerald Schaefer , Christian Borntraeger , Thomas Hellstrom , Ralph Campbell , Pasha Tatashin , Vasily Gorbik , Jann Horn , Heiko Carstens , Qi Zheng , Suren Baghdasaryan , Vlastimil Babka , Linux ARM , SeongJae Park , Lorenzo Stoakes , Linux-MM , linuxppc-dev , Naoya Horiguchi , Zack Rusin , Zach O'Keefe , Vishal Moola , Minchan Kim , "Kirill A. Shutemov" , Andrew Morton , Mel Gorman , "David S. Miller" , Mike Rapoport , Mike Kravetz Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, Aug 22, 2023 at 11:34:19AM -0700, Hugh Dickins wrote: > (Yes, the locking is a bit confusing: but mainly for the unrelated reason, > that with the split locking configs, we never quite know whether this lock > is the same as that lock or not, and so have to be rather careful.) Is it time to remove the PTE split locking config option? I believe all supported architectures have at least two levels of page tables, so if we have split ptlocks, ptl and pml are always different from each other (it's just that on two level machines, pmd == pud == p4d == pgd). With huge thread counts now being the norm, it's hard to see why anybody would want to support SMP and !SPLIT_PTE_PTLOCKS. To quote the documentation ... Split page table lock for PTE tables is enabled compile-time if CONFIG_SPLIT_PTLOCK_CPUS (usually 4) is less or equal to NR_CPUS. If split lock is disabled, all tables are guarded by mm->page_table_lock. You can barely buy a wrist-watch without eight CPUs these days.