Re: [RFC PATCH 8/8] HACK: mm: memory_hotplug: Drop memblock_phys_free() call in try_remove_memory()

From: Oscar Salvador <osalvador@suse.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	linux-cxl@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Sudeep Holla <sudeep.holla@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@redhat.com>,
	Will Deacon <will@kernel.org>, Jia He <justin.he@arm.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	linuxarm@huawei.com, catalin.marinas@arm.com,
	Anshuman.Khandual@arm.com,
	Yuquan Wang <wangyuquan1236@phytium.com.cn>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	James Morse <james.morse@arm.com>
Subject: Re: [RFC PATCH 8/8] HACK: mm: memory_hotplug: Drop memblock_phys_free() call in try_remove_memory()
Date: Thu, 30 May 2024 12:07:37 +0200	[thread overview]
Message-ID: <ZlhP6aMUOjx_EziA@localhost.localdomain> (raw)
In-Reply-To: <20240529171236.32002-9-Jonathan.Cameron@huawei.com>

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.

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.

Would that work?
I am not sure, but you might need to 

-- 
Oscar Salvador
SUSE Labs

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel