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 B87D5CD11BF for ; Mon, 25 Mar 2024 15:24:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3340E6B008A; Mon, 25 Mar 2024 11:24:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E4406B008C; Mon, 25 Mar 2024 11:24:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1AB666B0092; Mon, 25 Mar 2024 11:24:44 -0400 (EDT) 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 0A4686B008A for ; Mon, 25 Mar 2024 11:24:44 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BFAB4A0696 for ; Mon, 25 Mar 2024 15:24:43 +0000 (UTC) X-FDA: 81935933646.15.D1EE9EF Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf28.hostedemail.com (Postfix) with ESMTP id DD17CC0017 for ; Mon, 25 Mar 2024 15:24:40 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of sunnanyong@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=sunnanyong@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711380281; 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; bh=Uqms0HuvHOIzPGuGrg2DlhNwdt4CiBsOsP5kgK9SO3s=; b=CrK2WcOnsDRenTG5S0sY1gAJN5kQs553QzWJUGd9njZ2nNwqb0hbYDBnnLcfoUSHMloGxI Pf9Ngz4mQEcQzTsgK2z53c04+Ix5bXgQ8Seb7fqEpL+RbKkFvmJZEst7Sjj5OCTpVRv/6V BaQlv2A9b0PzFPU4RZHVbGm5mo5m3GQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711380281; a=rsa-sha256; cv=none; b=bppHylqZgBEXpcsalIhkRDI0OqIAuo6GjavRWSUJIEGYDIkvQ0AzInULb7tR1SoD9ZuRMd Zyifn2s8FYVc/aNEgyNZKgQk9VVMx63f0fBYvz5GX3Tvx7xSo50QQ/zvFZKVEPxW0kFQsB HuSayF/ILPH/q8SNyQlNNUl5y1Q5EBY= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of sunnanyong@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=sunnanyong@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4V3Gqz73GmzXjkc; Mon, 25 Mar 2024 23:21:51 +0800 (CST) Received: from kwepemm600003.china.huawei.com (unknown [7.193.23.202]) by mail.maildlp.com (Postfix) with ESMTPS id 5AFB9140ABF; Mon, 25 Mar 2024 23:24:36 +0800 (CST) Received: from [10.174.179.79] (10.174.179.79) by kwepemm600003.china.huawei.com (7.193.23.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 25 Mar 2024 23:24:35 +0800 Subject: Re: [PATCH v3 0/3] A Solution to Re-enable hugetlb vmemmap optimize To: David Rientjes , Will Deacon CC: Catalin Marinas , Matthew Wilcox , , Andrew Morton , , , , , , Yu Zhao , Yosry Ahmed , Sourav Panda References: <20240113094436.2506396-1-sunnanyong@huawei.com> <20240207111252.GA22167@willie-the-truck> <44075bc2-ac5f-ffcd-0d2f-4093351a6151@huawei.com> <20240208131734.GA23428@willie-the-truck> From: Nanyong Sun Message-ID: <22c14513-af78-0f1d-5647-384ff9cb5993@huawei.com> Date: Mon, 25 Mar 2024 23:24:34 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.79] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemm600003.china.huawei.com (7.193.23.202) X-Stat-Signature: um5dhzu4thkpoyjx4h685nnaxy6bm798 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: DD17CC0017 X-Rspam-User: X-HE-Tag: 1711380280-237465 X-HE-Meta: U2FsdGVkX18sOetUDpNIaZuz2h3uIq+0ccxbxZi2W8p8t1KlmZZABXQxalEok+f8TELWiB4dCTXAK/csGeJlJz+njZTPElOYn1jZ8rCpIGLDpH16YImREI/tw1wj15VV2vQJtwwMbA/YV5sZQC+kGW1zKjra9luFxLsuwOmm9n8/XuWBhlXNOkka20tIg10hsgUMv56Pgp5Bi9lUxpkbxpqOov1nQ7lNk0Sos8zJZRCLDZXMc7AriB7mSAVaPCrA+DQuZOKhU9/vPwHMQGs5NaoAZjEuwrOGdCj5j5YmPIfWKuo2o1+zhfYqhgwodXAAqWXwkkgkF2PSAciAqlkUCTl06Wd1IG2EawXZuNgdTYvMt8tbkmFVYOFVYmcKrCYeiAA0BTcuir8RF/eMzy38XQfm4ztvoRfC9tz/A1/3aOwW2Q0ae6VW6JScLaDk9T9dHUcPiNZVlL0o6ez/3NbOFL4paDC9zVwcU51ub8INkG36KJn5819LpN7H/nsfCr8XNmyhKArPj9q/4FtHQmoZ/iGs3+11PuSqrTdqy7eJuRVn3DMP+f+54YI69SkgERn2Ej5txFyag7AqmLqgxhA9OEhf6CCKIV7BPIIZN+ZIQ39tPMKfvrL8345e2HVV27GAQmXLqwzo9ltKdnNSE+sQyPrQGNr78V3OdRLvuFseGHpkTchWZoy3rEwBj9DtIN38vlg69HeEv2ukV7f7leJ5RkZYrFRYq9sFq/pHztnanCzCd+ekrluV87mQu3xn1wnCkzjDz5wegT6ELBb0E6vbnZNoJfwWjvhAnLWeRLI9y2awaV/zSi3c4TKq0mCvCCX6xI4lrDmEEmDnfQ0TOlpEajUDMmm1Yc0pJ377Vn5OYElb5Jnm0s4ILl46hsH4qRDBBYeIKxfzK2uWzu7EBNk+RC2UxeYsqRNJS5UEGYCGToZY5HgJ2OP16wysZ6Bki0+UHu+TOLnMxN/zTTTYwhd MIM6tROo ABRoJmevmjfA7n8bCPlhxPEFPnlF0sUU2M8LGEqTuevvT5IG0+o8B70VCnMuynG+zL1B2S1UW2HJAQpLUmeVo2cxghnVyF0B6I81H/ZAlkmNaiIoBh7xv0Zyj9burOtdniijbF4v/LDORqvyESsaoRr3RGPAjJV4Hrwe1 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 2024/3/14 7:32, David Rientjes wrote: > On Thu, 8 Feb 2024, Will Deacon wrote: > >>> 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) >>> +{ >>> +    (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 >> >> > Nanyong, are you still actively working on making HVO possible on arm64? > > This would yield a substantial memory savings on hosts that are largely > configured with hugetlbfs. In our case, the size of this hugetlbfs pool > is actually never changed after boot, but it sounds from the thread that > there was an idea to make HVO conditional on FEAT_BBM. Is this being > pursued? > > If so, any testing help needed? I'm afraid that FEAT_BBM may not solve the problem here, because from Arm ARM, I see that FEAT_BBM is only used for changing block size. Therefore, in this HVO feature, it can work in the split PMD stage, that is, BBM can be avoided in vmemmap_split_pmd, but in the subsequent vmemmap_remap_pte, the Output address of PTE still needs to be changed. I'm afraid FEAT_BBM is not competent for this stage. Perhaps my understanding of ARM FEAT_BBM is wrong, and I hope someone can correct me. Actually, the solution I first considered was to use the stop_machine method, but we have products that rely on /proc/sys/vm/nr_overcommit_hugepages to dynamically use hugepages, so I have to consider performance issues. If your product does not change the amount of huge pages after booting, using stop_machine() may be a feasible way. So far, I still haven't come up with a good solution.