From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Subject: Re: [PATCH RFC v4 08/13] mm/memory_hotplug: Introduce offline_and_remove_memory() Date: Mon, 2 Mar 2020 13:53:08 +0100 Message-ID: References: <20191212171137.13872-1-david@redhat.com> <20191212171137.13872-9-david@redhat.com> <20200225141134.GU22443@dhcp22.suse.cz> <20200302124852.GJ4380@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: <20200302124852.GJ4380@dhcp22.suse.cz> Content-Language: en-US To: Michal Hocko Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, virtio-dev@lists.oasis-open.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, Andrew Morton , "Michael S . Tsirkin" , Oscar Salvador , Pavel Tatashin , Wei Yang , Dan Williams , Qian Cai List-Id: virtualization@lists.linuxfoundation.org On 02.03.20 13:48, Michal Hocko wrote: > On Tue 25-02-20 15:27:28, David Hildenbrand wrote: >> On 25.02.20 15:11, Michal Hocko wrote: >>> On Thu 12-12-19 18:11:32, David Hildenbrand wrote: >>>> virtio-mem wants to offline and remove a memory block once it unplugged >>>> all subblocks (e.g., using alloc_contig_range()). Let's provide >>>> an interface to do that from a driver. virtio-mem already supports to >>>> offline partially unplugged memory blocks. Offlining a fully unplugged >>>> memory block will not require to migrate any pages. All unplugged >>>> subblocks are PageOffline() and have a reference count of 0 - so >>>> offlining code will simply skip them. >>>> >>>> All we need an interface to trigger the "offlining" and the removing in a >>>> single operation - to make sure the memory block cannot get onlined by >>>> user space again before it gets removed. >>> >>> Why does that matter? Is it really likely that the userspace would >>> interfere? What would be the scenario? >> >> I guess it's not that relevant after all (I think this comment dates >> back to the times where we didn't have try_remove_memory() and could >> actually BUG_ON() in remove_memory() if there would have been a race). >> Can drop that part. >> >>> >>> Or is still mostly about not requiring callers to open code this general >>> patter? >> >> From kernel module context, I cannot get access to the actual memory >> block device (find_memory_block()) and call the device_unregister(). >> >> Especially, also the device hotplug lock is not exported. So this is a >> clean helper function to be used from kernel module context. (e.g., also >> hyper-v showed interest for using that) > > Fair enough. > I'll send a v1 shortly, I rephrased the description to make this clear. Thanks! -- Thanks, David / dhildenb