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 82C58C4828F for ; Thu, 8 Feb 2024 13:17:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1C4B36B007D; Thu, 8 Feb 2024 08:17:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 175336B007E; Thu, 8 Feb 2024 08:17:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03BC76B0080; Thu, 8 Feb 2024 08:17:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E77E56B007D for ; Thu, 8 Feb 2024 08:17:44 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C3C7E408A7 for ; Thu, 8 Feb 2024 13:17:44 +0000 (UTC) X-FDA: 81768688848.08.6021D4A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id E339840012 for ; Thu, 8 Feb 2024 13:17:41 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=nGYDgmKZ; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707398262; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7FaKkCPKFQAdIXk8pP/6/TldC2A3uJws2ARUyY1ti8U=; b=gsQAKWdycKiwm14paE6bSpS7vVhmKdf+aSyJYZwqpGg8mWRcv8C1A0YhyOPL7RMFGEBL3f hcuTZQxQuKMgbg7Knj+u9apSA1QQol5WYIKwnD1M+pM4ad5Sk0kCiW8HNzjVVCg3MHdAIt iqEV0CHPJEwgV0R+DdUGKXCPxXq1yKA= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=nGYDgmKZ; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707398262; a=rsa-sha256; cv=none; b=FUJbDsnNU8QTUgmGRr00u3gooUBxwSwMl8tkgf2yzZbHayHi3PNbNmGFsJ0rcuMy60atom iqP2UDZETwuA5gInqtZ40iyztTvgC0zW7fbe6T5U/hKKvaGxPbVXeSGEmREqHiCfqGTFih y6Knm6pJxh+Vpq0ywyV7pG+NkVseonE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id F282E61D1D; Thu, 8 Feb 2024 13:17:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A9B3C433F1; Thu, 8 Feb 2024 13:17:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707398260; bh=rfFaoOvWoMWSRfibASMU8lqwrNttyoGnh9WN0nUfRvI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nGYDgmKZzTJAEXufSJ0dOeZAyQAONBsR9/SAw+vl5F8ERqrCbEpJkqTMwF0zkzc0W jzSpVHSejeScDQRRgqvCstV7TrHY127o5Qz63TGko1dOvXIpCe5Hjn8yWH4lDSBXs4 u8/c8f2p6WH3XHdlsalrCB9o6VyzuZi5H9cnwt9qV51FXTdIIc6ne2e73OkJpJrCNd 108tuwuNs3Zcl0vhpuwIKh3mvxX8ajmT+lTwx3Ip2wlMusbkyBwfd+uDvYFA+Ti1Jt tdFMpN8HzubOZ8oyUgCRMMQMGZceF5eF6Mnb3brXtoroqh7R9zS/x8CoAjnbCpAkCr hgWZ0F0CjT4xg== Date: Thu, 8 Feb 2024 13:17:34 +0000 From: Will Deacon To: Nanyong Sun Cc: Catalin Marinas , Matthew Wilcox , mike.kravetz@oracle.com, muchun.song@linux.dev, akpm@linux-foundation.org, anshuman.khandual@arm.com, wangkefeng.wang@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v3 0/3] A Solution to Re-enable hugetlb vmemmap optimize Message-ID: <20240208131734.GA23428@willie-the-truck> References: <20240113094436.2506396-1-sunnanyong@huawei.com> <20240207111252.GA22167@willie-the-truck> <44075bc2-ac5f-ffcd-0d2f-4093351a6151@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <44075bc2-ac5f-ffcd-0d2f-4093351a6151@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: E339840012 X-Stat-Signature: 3po3pys4hig6t3k6fmrb4koscnr1qtbj X-Rspam-User: X-HE-Tag: 1707398261-82104 X-HE-Meta: U2FsdGVkX18+lqD8kaVSghDG3d9EGFYfLH6OAJlBbA0nVuiXk7FP00zYqSzR1/KaytZ2pkFwBVhI+2ZDszHWhosu9dEH+9i3bn4PWnt2WT3LaFpmYI/8bTNhEaQ9s1EcTH/yyOMWAgYvBqiJugKA6dtKKiStfCJqeYMdsaEKK81Yp+mMAqfR3IcMNue9W94kNNX81P700l/K8kWFwIDZ/M7v/cH/ygLV8gLf8Ie98qd3P8ECznsqd5+gexm9RqlE9tiIRWIab9fVts53keGNIuvMOvA6z8iOL01/1LgP4TNYkb2IocvJFaJjzaqK8NIWmQqEHMT2+1qpjZrSsO7F52YOc4sS2UsHYEwGKlL78AvhYbtmrDeZzQWYlMj42fv5yynlnGo3oYussaHtX/AY7HQcab9q9+u7bZ1i0j3jTS3dCT/koF40tyoA1gy7leMNhOF9TAFEdFZb7LqI2NhzDdzZfB7fjgThmtMbTm8LBU0BTqNqauHpIFCz+4qOHcbZDwJU3e5ZnsIljwqYo3wOMPpBwyQF2F88c1RiJHOkSGumJI9tlLj8zLb7YcaXQi1Km/SGlNqwXRo6Nx68gXOw1CJ24jSM21YVdaoxQy4B++TuHOiXjCN+OczuqLbu/XS6t/sgYGcedMC59MNISqLyHXpLhNFBVZRAIK0fskQtEt0gTlMvCFx5ATlQlw4enyWEwVuEVp9F5DPgVYirB41y6u/E7SZ0U4fDNDGo2Vp5/ydG8yLDRfsUU7ZKPkLvalN/BBbh+ahJ1aV35Eg8J93Q8h/2n9mC5loUfkC6T5XQIp4X4Jy3MgaQrTEiIymgeZT9TXjwDNxrwHfIzFyLcbfdMYk8/EouPKPE6oFpZf3SNoJwfcjGClhffgYbM3d1TdJXiT3/shNYB7t+77OWi3MkKhpM8QaVLhmHjdKhKe3KnGZUeX2b1/IHaYYnq6wu91+Z9ZA4Eb0Q8y8q7VTS3gu p9/Vf5ad dRvVkWd0dU6/RGpJIYTWKeezpsNZhhD48Xt4sntEGsOgVhQJCgRqZ2TcyfzfhGTPjPT4KjTrUj9k7BIpdmGdESSwCGpH908euzpSAzLQk43H49pEybXqnxIlCaFg4O7DGpmA3UyG6HQ2V14odVJaPZsQ9nf0ROuovnk81H8WvyDyQVDULmNnG5IOd5o5hXPBOtqNU8m0s51JRpZQHs34mKAxIVO/Wn6mKvdEj7zio9nedOzs= 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 Thu, Feb 08, 2024 at 05:44:48PM +0800, Nanyong Sun wrote: > > 在 2024/2/7 20:20, Catalin Marinas 写道: > > On Wed, Feb 07, 2024 at 11:21:17AM +0000, Matthew Wilcox wrote: > > > On Wed, Feb 07, 2024 at 11:12:52AM +0000, Will Deacon wrote: > > > > On Sat, Jan 27, 2024 at 01:04:15PM +0800, Nanyong Sun wrote: > > > > > On 2024/1/26 2:06, Catalin Marinas wrote: > > > > > > On Sat, Jan 13, 2024 at 05:44:33PM +0800, Nanyong Sun wrote: > > > > > > > HVO was previously disabled on arm64 [1] due to the lack of necessary > > > > > > > BBM(break-before-make) logic when changing page tables. > > > > > > > This set of patches fix this by adding necessary BBM sequence when > > > > > > > changing page table, and supporting vmemmap page fault handling to > > > > > > > fixup kernel address translation fault if vmemmap is concurrently accessed. > > > > > > I'm not keen on this approach. I'm not even sure it's safe. In the > > > > > > second patch, you take the init_mm.page_table_lock on the fault path but > > > > > > are we sure this is unlocked when the fault was taken? > > > > > I think this situation is impossible. In the implementation of the second > > > > > patch, when the page table is being corrupted > > > > > (the time window when a page fault may occur), vmemmap_update_pte() already > > > > > holds the init_mm.page_table_lock, > > > > > and unlock it until page table update is done.Another thread could not hold > > > > > the init_mm.page_table_lock and > > > > > also trigger a page fault at the same time. > > > > > If I have missed any points in my thinking, please correct me. Thank you. > > > > It still strikes me as incredibly fragile to handle the fault and trying > > > > to reason about all the users of 'struct page' is impossible. For example, > > > > can the fault happen from irq context? > > > The pte lock cannot be taken in irq context (which I think is what > > > you're asking?) > > With this patchset, I think it can: IRQ -> interrupt handler accesses > > vmemmap -> faults -> fault handler in patch 2 takes the > > init_mm.page_table_lock to wait for the vmemmap rewriting to complete. > > Maybe it works if the hugetlb code disabled the IRQs but, as Will said, > > such fault in any kernel context looks fragile. > How about take a new lock with irq disabled during BBM, like: > > +void vmemmap_update_pte(unsigned long addr, pte_t *ptep, pte_t pte) > +{ > +    spin_lock_irq(NEW_LOCK); > +    pte_clear(&init_mm, addr, ptep); > +    flush_tlb_kernel_range(addr, addr + PAGE_SIZE); > +    set_pte_at(&init_mm, addr, ptep, pte); > +    spin_unlock_irq(NEW_LOCK); > +} I really think the only maintainable way to achieve this is to avoid the possibility of a fault altogether. Will