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. -- Michal Hocko SUSE Labs
