From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by kanga.kvack.org (Postfix) with ESMTP id 6910F6B2D62 for ; Thu, 22 Nov 2018 16:28:25 -0500 (EST) Received: by mail-ed1-f69.google.com with SMTP id e29so5041956ede.19 for ; Thu, 22 Nov 2018 13:28:25 -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 w7-v6sor1580797eja.24.2018.11.22.13.28.23 for (Google Transport Security); Thu, 22 Nov 2018 13:28:23 -0800 (PST) Date: Thu, 22 Nov 2018 21:28:22 +0000 From: Wei Yang Subject: Re: [PATCH v2] mm, hotplug: move init_currently_empty_zone() under zone_span_lock protection Message-ID: <20181122212822.ypedpcbhrxpa3tyv@master> Reply-To: Wei Yang References: <20181120014822.27968-1-richard.weiyang@gmail.com> <20181122101241.7965-1-richard.weiyang@gmail.com> <18088694-22c8-b09b-f500-4932b6199004@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18088694-22c8-b09b-f500-4932b6199004@redhat.com> Sender: owner-linux-mm@kvack.org List-ID: To: David Hildenbrand Cc: Wei Yang , mhocko@suse.com, osalvador@suse.de, akpm@linux-foundation.org, linux-mm@kvack.org On Thu, Nov 22, 2018 at 04:26:40PM +0100, 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 >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. > >mem_hotplug_begin() is just an internal optimization. (we don't want > everybody to take the device lock) > Hi, David Thanks for your comment. Hmm... I didn't catch your point. Related to memory hot-plug, there are (at least) three locks, * device_hotplug_lock (global) * device lock (device scope) * mem_hotplug_lock (global) But with two different hold sequence in two cases: * device_online() device_hotplug_lock device_lock mem_hotplug_lock * add_memory_resource() device_hotplug_lock mem_hotplug_lock device_lock ^ | I don't find where this is hold in add_memory_resource(). Would you mind giving me a hint? If my understanding is correct, what is your point? I guess your point is : just remove mem_hotplug_lock is not enough to resolve the scalability issue? Please correct me, if I am not. :-) -- Wei Yang Help you, Help me