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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 C3F65C6FD1F for ; Tue, 26 Mar 2024 12:54:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=lx9+ze1/M3hD507OK2l2a+OWZTFfU4SOLtPk+i3+J7U=; b=IawPt8Apl78YU2 IEft7LX4GxMA9ucZNIAdd6TEhdzdWP/GH9lnqCHj0yhI6z3Y0P0IoKAPATjn/Bh1CJWUYz2V7qAet ndNZPTBOmLZYPvcdiUF91TMW66bbVDckbvaX0X7IXmlEQJQFBpwPaOxPfp+otEdFi1nt0YjtRcKmf 7TcasFwz9X2IYSTwqOiXNhvsiBYbxVhOMKOrOr3MWtYvExqpNGRhE3kxWsGu3kVXzrCKhYlKLCLKl BVFTYq19vpzEoHE0IT4rhffhUN7l5CsMqbqtvHez+nemVvk9mETGrGmQSI/d14qCsJ6h4L017c3HV Ogya8E/vCKFKVlqckyQw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rp6Jp-00000004Y7a-3so0; Tue, 26 Mar 2024 12:54:21 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rp6Jm-00000004Y6q-46Sz for linux-arm-kernel@lists.infradead.org; Tue, 26 Mar 2024 12:54:20 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 2AD60CE2101; Tue, 26 Mar 2024 12:54:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DEEEBC433C7; Tue, 26 Mar 2024 12:54:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711457656; bh=HANE9Ck98nA4yLDO1qZtV2vsNr/fyY+1mdplJg0Nl0w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=J9PmjWXAuvpNf0kNeIJ0S0w4XhOn94evh/3pN3bRrDW2/KVo+R51sJ3qo5GE1elZP f5Wkxt40uLV+bjhEf0PkwctDFfveSWI+k/otPA46eBO8agrwarzJp8aAWAIhNzOiH1 2qUZyC9O+TrOvy/J4jEajfH8bBlf3sHoq3vit2j/x8qWEI5CFIuBzIarSvh5ptim1d RZo4rEcaoxRcqSRs4k/PXDSRybpM7rH3VvtkgeHzhdbniaU7FwF5mocez2Foim4YXY 2xuI9jLgUvoLTYVVcO6/IRIwLpAuwQQJYx0FnEhVK9OOMYeMzaqMu5kV/da7HkDX+1 /RPLaXzvje0kA== Date: Tue, 26 Mar 2024 12:54:10 +0000 From: Will Deacon To: Nanyong Sun Cc: David Rientjes , Catalin Marinas , Matthew Wilcox , muchun.song@linux.dev, Andrew Morton , anshuman.khandual@arm.com, wangkefeng.wang@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Yu Zhao , Yosry Ahmed , Sourav Panda Subject: Re: [PATCH v3 0/3] A Solution to Re-enable hugetlb vmemmap optimize Message-ID: <20240326125409.GA9552@willie-the-truck> References: <20240113094436.2506396-1-sunnanyong@huawei.com> <20240207111252.GA22167@willie-the-truck> <44075bc2-ac5f-ffcd-0d2f-4093351a6151@huawei.com> <20240208131734.GA23428@willie-the-truck> <22c14513-af78-0f1d-5647-384ff9cb5993@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <22c14513-af78-0f1d-5647-384ff9cb5993@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240326_055419_405641_EB2E624F X-CRM114-Status: GOOD ( 29.62 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Mar 25, 2024 at 11:24:34PM +0800, Nanyong Sun wrote: > 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) > > > > +{ > > > > +=A0=A0=A0 (NEW_LOCK); > > > > +=A0=A0=A0 pte_clear(&init_mm, addr, ptep); > > > > +=A0=A0=A0 flush_tlb_kernel_range(addr, addr + PAGE_SIZE); > > > > +=A0=A0=A0 set_pte_at(&init_mm, addr, ptep, pte); > > > > +=A0=A0=A0 spin_unlock_irq(NEW_LOCK); > > > > +} > > > I really think the only maintainable way to achieve this is to avoid = the > > > possibility of a fault altogether. > > > = > > 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 t= his > 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. Oh, I hadn't appreciated that you needed to remap the memmap live. How do you synchronise the two copies in that case? I think we (i.e. the arch folks) probably need some more explanation on exactly who can race with what here, otherwise I don't grok how this can work. Thanks, Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel