On 23.11.18 09:42, Michal Hocko wrote: > On Thu 22-11-18 16:26:40, David Hildenbrand wrote: >> On 22.11.18 11:12, Wei Yang wrote: >>> During online_pages phase, pgdat->nr_zones will be updated in case this >>> zone is empty. >>> >>> Currently the online_pages phase is protected by the global lock >>> mem_hotplug_begin(), which ensures there is no contention during the >>> update of nr_zones. But this global lock introduces scalability issues. >>> >>> This patch is a preparation for removing the global lock during >>> online_pages phase. Also this patch changes the documentation of >>> node_size_lock to include the protectioin of nr_zones. >> >> I looked into locking recently, and there is more to it. >> >> Please read: >> >> commit dee6da22efac451d361f5224a60be2796d847b51 >> Author: David Hildenbrand <david@xxxxxxxxxx> >> Date: Tue Oct 30 15:10:44 2018 -0700 >> >> memory-hotplug.rst: add some details about locking internals >> >> Let's document the magic a bit, especially why device_hotplug_lock is >> required when adding/removing memory and how it all play together with >> requests to online/offline memory from user space. >> >> Short summary: Onlining/offlining of memory requires the device_hotplug_lock >> as of now. > > Well, I would tend to disagree here. You might be describing the current > state of art but the device_hotplug_lock doesn't make much sense for the > memory hotplug in principle. There is absolutely nothing in the core MM There are collisions with CPU hotplug that require this lock (when nodes come and go as far as I remember). And there is the problematic lock inversion that can happen when adding/remving memory. This all has to be sorted out, we'll have to see if we really need it for onlining/offlining, though, however ... > that would require this lock. The current state just uses a BKL in some > sense and we really want to get rid of that longterm. This patch is a tiny > step in that direction and I suspect many more will need to come on the > way. We really want to end up with a clear scope of each lock being > taken. A project for a brave soul... ... for now I don't consider "optimize for parallel onlining/offlining/adding/removing of memory and cpus" really necessary. What is necessary indeed is to not slowdown the whole system just because some memory is coming/going. Therefore I agree, this patch is a step into the right direction. -- Thanks, David / dhildenb
