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 B0003C25B74 for ; Thu, 30 May 2024 12:15:11 +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:MIME-Version:References:In-Reply-To: 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=gCwDC8gTkGEHqxCsAQz3I7c1jTdDsF3/r2JDzqKs1FQ=; b=k8nF6ZKOlMUT+q V1rHwVIfmZBItSLNd0EiAd37wmg5xg/jlII39NexWbqzG6HxmdHGZI6W4k+XWNfhKefCc6ALc8i4t l/ESSlO2Up8Vi7vqtfruqDwVPBnNDfrYSc+ZXqpo5bR/M4OviAdWInVGunwr1W/c7crJx95od+RF3 S++VTdD2DhZKRIAXqme4YexrQVBXdZjHUsxhg8HbtZ6fgDEluBUTpe5qImR55ih9tn15oVlgzWSCf qKekp8srG4LazlghtK5eL4h9TK2aVsKzOfbPBdKS14RkAIp7Pa8l/HQ3Er00r7Hs2ZK+Qu8EbT+ns TeDzGR1LyK+NWZhosfxw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sCegL-00000007C8G-14la; Thu, 30 May 2024 12:14:57 +0000 Received: from frasgout.his.huawei.com ([185.176.79.56]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sCegH-00000007C7n-2yvT for linux-arm-kernel@lists.infradead.org; Thu, 30 May 2024 12:14:55 +0000 Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VqlSd2YNWz6K63S; Thu, 30 May 2024 20:10:25 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 93A961400D7; Thu, 30 May 2024 20:14:42 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 30 May 2024 13:14:42 +0100 Date: Thu, 30 May 2024 13:14:41 +0100 From: Jonathan Cameron To: Oscar Salvador CC: Dan Williams , , , Sudeep Holla , Andrew Morton , David Hildenbrand , Will Deacon , Jia He , Mike Rapoport , , , , Yuquan Wang , Lorenzo Pieralisi , James Morse Subject: Re: [RFC PATCH 8/8] HACK: mm: memory_hotplug: Drop memblock_phys_free() call in try_remove_memory() Message-ID: <20240530131441.000020bd@Huawei.com> In-Reply-To: References: <20240529171236.32002-1-Jonathan.Cameron@huawei.com> <20240529171236.32002-9-Jonathan.Cameron@huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml100001.china.huawei.com (7.191.160.183) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240530_051453_934437_B4FB09D2 X-CRM114-Status: GOOD ( 29.38 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 30 May 2024 12:07:37 +0200 Oscar Salvador wrote: > On Wed, May 29, 2024 at 06:12:36PM +0100, Jonathan Cameron wrote: > > I'm not sure what this is balancing, but it if is necessary then the reserved > > memblock approach can't be used to stash NUMA node assignments as after the > > first add / remove cycle the entry is dropped so not available if memory is > > re-added at the same HPA. > > It is balancing previously allocated memory which was allocated via > memblock_phys_alloc{_range,try_nid}. > memblock_phys_alloc_try_nid() is who does the heavy-lifting, and also calls > kmemleak_alloc_phys() to make kmemleak aware of that memory. Thanks Oscar, I'm struggling to find the call path that does that for the particular range being released. There are some calls to allocate node data but for small amounts of data whereas I think this call is removing the full range of the hot removed memory. Is the intent just to get rid of the node data related reserved memblock if it happens to be in the memory removed? If so feels like the call should really be targetting just that. > > A quick idea that came to me is: > I think that it should be possible 1) create a new memory_block flag > (check 'enum memblock_flags') and 2) flag the range you want with this > range (check memblock_setclr_flag()) with a function like > memblock_reserved_mark_{yourflag}. > > Then, in memblock_phys_free() (or down the path) we could check for that flag, > and refuse to proceed if it is set. I had tried a flag in the main memblock rather than using the reserved memblock a while back and that was horribly invasive so I got a bit scared of touching those flags. One used only in the reserved memblock might work to bypass the removal of the reserved memblocks but carry out everything else that call is intended to do. I'm still sketchy on what I'm bypassing though! Thanks, Jonathan > > Would that work? > I am not sure, but you might need to > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel