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 2250DC47258 for ; Thu, 25 Jan 2024 18:06:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AAD6E6B008C; Thu, 25 Jan 2024 13:06:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A5D946B0092; Thu, 25 Jan 2024 13:06:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 94C676B0093; Thu, 25 Jan 2024 13:06:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 836EB6B008C for ; Thu, 25 Jan 2024 13:06:28 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1E861160CBB for ; Thu, 25 Jan 2024 18:06:28 +0000 (UTC) X-FDA: 81718613256.18.CCBE11B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf07.hostedemail.com (Postfix) with ESMTP id 6FACC40010 for ; Thu, 25 Jan 2024 18:06:26 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706205986; 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: in-reply-to:in-reply-to:references:references; bh=wS4X17240hW5y6LqImy6lF0Qfb1xrdQnZpun4ihgGxA=; b=qoXbnL/q12zZ9Fpd9N2p3iE3XCBtRvpNLsQHFmUlEvXLj92a/y3U6ZUQcy94RtgFvIOevx dLEIgEh0k7Z0JkWNyrkgXC06uYpth/fFQyBny3nveAwLgf6Wdq6f/KFWTdyJXGAeyyoq3a +QKu5Gy9nO3R86hhD6oBkSqQQrV2bDQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706205986; a=rsa-sha256; cv=none; b=RCFLOPjaUa6Oa3GVHtc+wSexZGafEOq6CAKQ+1sBLlhj4AI0ASxVFXqRw3qXefPr56yiAx XPKS+s5oN7RyOLecljKKnVnluuRxBl7bnU70xOydqjXIVX2gF/nIBLIdhYVrLONX5y8jQO KPWjDUsHzdPWG51edhmIjOmqn0SN3So= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id AAD3D61503; Thu, 25 Jan 2024 18:06:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43125C433F1; Thu, 25 Jan 2024 18:06:23 +0000 (UTC) Date: Thu, 25 Jan 2024 18:06:20 +0000 From: Catalin Marinas To: Nanyong Sun Cc: will@kernel.org, mike.kravetz@oracle.com, muchun.song@linux.dev, akpm@linux-foundation.org, anshuman.khandual@arm.com, willy@infradead.org, 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: References: <20240113094436.2506396-1-sunnanyong@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240113094436.2506396-1-sunnanyong@huawei.com> X-Stat-Signature: g7rogk57wrz4ryajxgaw7pfur4mmg8zu X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 6FACC40010 X-Rspam-User: X-HE-Tag: 1706205986-671077 X-HE-Meta: U2FsdGVkX1/8o8k+Ly5r2TBd7j0TOnmir+f7hCRQvgHShrZMwvtNYISB2fzSXAKK2QWXAI3wZTNM4R9um0jv7ps8u/rB0zzEpQGUZVVwlVKlo3/4BVzUPrcdDNatIgd7ZnBGzfK5O7/6ZQeshVQIU/GTGUUrzJ7xBilCLFl4tZY7+4bjo/jWIB0sBc62/Uhkvg72Y7sHU8gqeelWIPVSdLgO5/V4oGofBWlojwyTok1Y651bf0ab4Ct3nHVKr26w6Vz42L5sY5ERihO1sSngvGwz7XVLxbQr4mYGSr6Q3bJ6wsy6gvB9WbSvXIjMrTCZRQlRxEmkX48JczURre0vVwxkCYSRr61tQTxvdInSTZWEsuv85UCcX9KR+OPEWfrgflraibFcw0b2QvrPMLBFO8VDGh/zjMhZAw5EiJxPBhxWFi6iers7rQoP/6AW94CoYzif4IaJIhXp9IzKPprljVOFBvD6UxfvB9bUjwysFL1cV35f94ALu9tJb9oK4csJcLgSTcP/Qirz4oxKmpXEAWTIroxMPNTDD6PTnLJs9en1hsbK/aty15JVBgXtNkJeK0jP1BaxTdM0BfvyCcVuENfAkvlJj5hDwWL1AKJn9NUdqNaPdQP+/MhzSaxTcdkhyqofLJoEJxd3NvP5beB0QIjW2zAOO+rzGCakiPRM2d8riMNx+bM8H4g9rSkNEktaZVUBlrqHt7BfoOp4N6SeN60lIIauZMMWwryPetYGHqUgFYGp85hTmfRKR/ZKD/vhn6jquWnpTLGyBCYnSjRSoGkyfO2wLFC4w6jSAKhTZ9dLAr3cjPtmzwxE6Rbz1pa+U+1GRf+WJ2426GR9iIIeQOl7pxBM8s9vhLflquwtJpX2AR6XWwtzUwJp4JfjXdIZSK89mq7JHDPGOCLdTqi7v5e4+vnBHFreXbCtbg4GBvA7oO9lm6mr32Jg30da+wb2kfOu0fs8BhmOGzDWDlP oUAD8TuM CTcah6d/zptwdwghrFU4T8Tb5T6yjSS/wMRO1QyHfjVhDAWYP7A3/jZfCSt+WbWWQzMrOW0LKgYAjoTr4oExAi8QEYkPgiA3IH9m2t68Bx+BBC/zKOeUolzUCyVxFWIOfvmCBQaPy4Zezee+FCdUZiqUGp6fs8qWybLLrPUnKUk6LQZdDRn1K4PWFXitu+5ossv17LZoZ/j7Qx1u7piTkH+bb+XWMl5zAh6j+oQcRy3JUmgxWUGZvhsq1Nsl1bfokhaTJ8YPAzj1Yu0aWqwKB2ddIKuDoCSvd0nvGNOucAGvk3py3zLpXANGvO/No0RU0h2niclQODLp0UOU7F5ITP9/MJMFxuoYQk6/rIlvSegrQkBg= 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 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? Basically you can get a fault anywhere something accesses a struct page. How often is this code path called? I wonder whether a stop_machine() approach would be simpler. Andrew, I'd suggest we drop these patches from the mm tree for the time being. They haven't received much review from the arm64 folk. Thanks. -- Catalin