From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by kanga.kvack.org (Postfix) with ESMTP id 241996B0005 for ; Mon, 12 Nov 2018 14:14:39 -0500 (EST) Received: by mail-qk1-f197.google.com with SMTP id s70so26267442qks.4 for ; Mon, 12 Nov 2018 11:14:39 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id b184sor9481216qke.10.2018.11.12.11.14.38 for (Google Transport Security); Mon, 12 Nov 2018 11:14:38 -0800 (PST) Date: Mon, 12 Nov 2018 19:14:34 +0000 From: Pavel Tatashin Subject: Re: [PATCH 2/5] mm/memory_hotplug: Create add/del_device_memory functions Message-ID: <20181112191434.z5ufchwele3fl6se@soleen.tm1wkky2jk1uhgkn0ivaxijq1c.bx.internal.cloudapp.net> References: <20181015153034.32203-1-osalvador@techadventures.net> <20181015153034.32203-3-osalvador@techadventures.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181015153034.32203-3-osalvador@techadventures.net> Sender: owner-linux-mm@kvack.org List-ID: To: Oscar Salvador Cc: akpm@linux-foundation.org, mhocko@suse.com, dan.j.williams@intel.com, yasu.isimatu@gmail.com, rppt@linux.vnet.ibm.com, malat@debian.org, linux-kernel@vger.kernel.org, pavel.tatashin@microsoft.com, jglisse@redhat.com, Jonathan.Cameron@huawei.com, rafael@kernel.org, david@redhat.com, dave.jiang@intel.com, linux-mm@kvack.org, alexander.h.duyck@linux.intel.com, Oscar Salvador On 18-10-15 17:30:31, Oscar Salvador wrote: > From: Oscar Salvador > > HMM/devm have a particular handling of memory-hotplug. > They do not go through the common path, and so, they do not > call either offline_pages() or online_pages(). > > The operations they perform are the following ones: > > 1) Create the linear mapping in case the memory is not private > 2) Initialize the pages and add the sections > 3) Move the pages to ZONE_DEVICE > > Due to this particular handling of hot-add/remove memory from HMM/devm, > I think it would be nice to provide a helper function in order to > make this cleaner, and not populate other regions with code > that should belong to memory-hotplug. > > The helpers are named: > > del_device_memory > add_device_memory > > The idea is that add_device_memory will be in charge of: > > a) call either arch_add_memory() or add_pages(), depending on whether > we want a linear mapping > b) online the memory sections that correspond to the pfn range > c) call move_pfn_range_to_zone() being zone ZONE_DEVICE to > expand zone/pgdat spanned pages and initialize its pages > > del_device_memory, on the other hand, will be in charge of: > > a) offline the memory sections that correspond to the pfn range > b) call shrink_zone_pgdat_pages(), which shrinks node/zone spanned pages. > c) call either arch_remove_memory() or __remove_pages(), depending on > whether we need to tear down the linear mapping or not > > The reason behind step b) from add_device_memory() and step a) > from del_device_memory is that now find_smallest/biggest_section_pfn > will have to check for online sections, and not for valid sections as > they used to do, because we call offline_mem_sections() in > offline_pages(). > > In order to split up better the patches and ease the review, > this patch will only make a) case work for add_device_memory(), > and case c) for del_device_memory. > > The other cases will be added in the next patch. > > These two functions have to be called from devm/HMM code: > > dd_device_memory: > - devm_memremap_pages() > - hmm_devmem_pages_create() > > del_device_memory: > - hmm_devmem_release > - devm_memremap_pages_release > > One thing I do not know is whether we can move kasan calls out of the > hotplug lock or not. > If we can, we could move the hotplug lock within add/del_device_memory(). > > Signed-off-by: Oscar Salvador Looks good to me, thank you. Reviewed-by: Pavel Tatashin Pasha