Re: [PATCH 2/2] core-api/memory-hotplug.rst: divide Locking Internal section by different locks

On Wed, Dec 05, 2018 at 09:08:47AM +0100, David Hildenbrand wrote:

On 05.12.18 03:34, Wei Yang wrote:

quoted

Currently locking for memory hotplug is a little complicated.

Generally speaking, we leverage the two global lock:

  * device_hotplug_lock
  * mem_hotplug_lock

to serialise the process.

While for the long term, we are willing to have more fine-grained lock
to provide higher scalability.

This patch divides Locking Internal section based on these two global
locks to help readers to understand it. Also it adds some new finding to
enrich it.

[David: words arrangement]

Signed-off-by: Wei Yang <redacted>
---
 Documentation/core-api/memory-hotplug.rst | 27 ++++++++++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/Documentation/core-api/memory-hotplug.rst b/Documentation/core-api/memory-hotplug.rst
index de7467e48067..95662b283328 100644
--- a/Documentation/core-api/memory-hotplug.rst
+++ b/Documentation/core-api/memory-hotplug.rst

@@ -89,6 +89,20 @@ NOTIFY_STOP stops further processing of the notification queue.
 Locking Internals
 =================
 
+There are three locks involved in memory-hotplug, two global lock and one local
+lock:
+
+- device_hotplug_lock
+- mem_hotplug_lock
+- device_lock
+

Do we really only ever use these three and not anything else when
adding/removing/onlining/offlining memory?

(I am thinking e.g. about pgdat_resize_lock)

Yes there are more than those three, pgdat_resize_lock is one of them.

If so, you should phrase that maybe more generally Or add more details :)

Yep, while I don't get a whole picture about the pgdat_resize_lock. The
usage of this lock scatter in many places.

"In addition to fine grained locks like pgdat_resize_lock, there are
three locks involved ..."

Sounds better :-)

-- 
Wei Yang
Help you, Help me