2021-06-09 17:13:13

by David Hildenbrand

[permalink] [raw]
Subject: [PATCH v3 0/2] memory-hotplug.rst: complete admin-guide overhaul

This is v3 of the memory hot(un)plug admin-guide overhaul.

v2 -> v3:
- Added ACKs and RBs (thanks!)
- s/aarch64/arm64/
- Refine error handling when onlining/offlining
- s/memory hotplug/memory offlining/ in the vmemmap optimization section
for huge pages

v1 -> v2:
- Added "memory-hotplug.rst: remove locking details from admin-guide"
- Incorporated all feedback from Mike and Michal (thanks!)
- Compressed some lines to make full use of 80 chars.
- Added details regarding 64bit/supported archs to the introduction.
- Added KASAN to the list of sizing considerations.

David Hildenbrand (2):
memory-hotplug.rst: remove locking details from admin-guide
memory-hotplug.rst: complete admin-guide overhaul

.../admin-guide/mm/memory-hotplug.rst | 800 ++++++++++--------
1 file changed, 455 insertions(+), 345 deletions(-)

--
2.31.1


2021-06-09 17:13:14

by David Hildenbrand

[permalink] [raw]
Subject: [PATCH v3 1/2] memory-hotplug.rst: remove locking details from admin-guide

We have the same content at Documentation/core-api/memory-hotplug.rst
and it doesn't fit into the admin-guide. The documentation was
accidentially duplicated when merging.

Acked-by: Mike Rapoport <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Reviewed-by: Oscar Salvador <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Oscar Salvador <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Mike Rapoport <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Anshuman Khandual <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: Pavel Tatashin <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Cc: [email protected]
Signed-off-by: David Hildenbrand <[email protected]>
---
.../admin-guide/mm/memory-hotplug.rst | 39 -------------------
1 file changed, 39 deletions(-)

diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst
index c6bae2d77160..a783cf7c8e4c 100644
--- a/Documentation/admin-guide/mm/memory-hotplug.rst
+++ b/Documentation/admin-guide/mm/memory-hotplug.rst
@@ -415,45 +415,6 @@ Need more implementation yet....
- Guard from remove if not yet.


-Locking Internals
-=================
-
-When adding/removing memory that uses memory block devices (i.e. ordinary RAM),
-the device_hotplug_lock should be held to:
-
-- synchronize against online/offline requests (e.g. via sysfs). This way, memory
- block devices can only be accessed (.online/.state attributes) by user
- space once memory has been fully added. And when removing memory, we
- know nobody is in critical sections.
-- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and PPC)
-
-Especially, there is a possible lock inversion that is avoided using
-device_hotplug_lock when adding memory and user space tries to online that
-memory faster than expected:
-
-- device_online() will first take the device_lock(), followed by
- mem_hotplug_lock
-- add_memory_resource() will first take the mem_hotplug_lock, followed by
- the device_lock() (while creating the devices, during bus_add_device()).
-
-As the device is visible to user space before taking the device_lock(), this
-can result in a lock inversion.
-
-onlining/offlining of memory should be done via device_online()/
-device_offline() - to make sure it is properly synchronized to actions
-via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type)
-
-When adding/removing/onlining/offlining memory or adding/removing
-heterogeneous/device memory, we should always hold the mem_hotplug_lock in
-write mode to serialise memory hotplug (e.g. access to global/zone
-variables).
-
-In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
-mode allows for a quite efficient get_online_mems/put_online_mems
-implementation, so code accessing memory can protect from that memory
-vanishing.
-
-
Future Work
===========

--
2.31.1

2021-06-13 23:22:23

by Jonathan Corbet

[permalink] [raw]
Subject: Re: [PATCH v3 0/2] memory-hotplug.rst: complete admin-guide overhaul

David Hildenbrand <[email protected]> writes:

> This is v3 of the memory hot(un)plug admin-guide overhaul.
>
> v2 -> v3:
> - Added ACKs and RBs (thanks!)
> - s/aarch64/arm64/
> - Refine error handling when onlining/offlining
> - s/memory hotplug/memory offlining/ in the vmemmap optimization section
> for huge pages

So this set doesn't apply to docs-next, even when I correct for the fact
that you didn't make the patch from the top-level kernel directory.
What tree is this against?

Thanks,

jon

2021-06-14 07:23:41

by David Hildenbrand

[permalink] [raw]
Subject: Re: [PATCH v3 0/2] memory-hotplug.rst: complete admin-guide overhaul

On 14.06.21 01:20, Jonathan Corbet wrote:
> David Hildenbrand <[email protected]> writes:
>
>> This is v3 of the memory hot(un)plug admin-guide overhaul.
>>
>> v2 -> v3:
>> - Added ACKs and RBs (thanks!)
>> - s/aarch64/arm64/
>> - Refine error handling when onlining/offlining
>> - s/memory hotplug/memory offlining/ in the vmemmap optimization section
>> for huge pages
>
> So this set doesn't apply to docs-next, even when I correct for the fact
> that you didn't make the patch from the top-level kernel directory.

Hi Jon,

oh, looks like I messed up v3 by git-format-patching from the wrong
directory ...

> What tree is this against?
>

Essentially against Andrew's mmotm, which already contains v1. Note
mmotm was chosen due to a conflict in:

https://lkml.kernel.org/r/[email protected]

I'd suggest we take this via Andrew's tree, unless you have other
preference on how to handle the conflict. Thanks!

> Thanks,
>
> jon
>


--
Thanks,

David / dhildenb

2021-06-14 14:16:21

by Jonathan Corbet

[permalink] [raw]
Subject: Re: [PATCH v3 0/2] memory-hotplug.rst: complete admin-guide overhaul

David Hildenbrand <[email protected]> writes:

> Essentially against Andrew's mmotm, which already contains v1. Note
> mmotm was chosen due to a conflict in:
>
> https://lkml.kernel.org/r/[email protected]
>
> I'd suggest we take this via Andrew's tree, unless you have other
> preference on how to handle the conflict. Thanks!

That's fine with me - one less thing for me to deal with :)

Thanks,

jon

2021-06-14 16:19:41

by David Hildenbrand

[permalink] [raw]
Subject: Re: [PATCH v3 0/2] memory-hotplug.rst: complete admin-guide overhaul

On 14.06.21 16:14, Jonathan Corbet wrote:
> David Hildenbrand <[email protected]> writes:
>
>> Essentially against Andrew's mmotm, which already contains v1. Note
>> mmotm was chosen due to a conflict in:
>>
>> https://lkml.kernel.org/r/[email protected]
>>
>> I'd suggest we take this via Andrew's tree, unless you have other
>> preference on how to handle the conflict. Thanks!
>
> That's fine with me - one less thing for me to deal with :)
>

Thanks!


FWIW, the patches are fine. My setup simply seems to compress the file
paths in the diff stats more aggressively:

$ git format-patch -2 -v3 > /dev/null; cat v3-0000-cover-letter.patch | tail -6
.../admin-guide/mm/memory-hotplug.rst | 800 ++++++++++--------
1 file changed, 455 insertions(+), 345 deletions(-)


When I force to a bigger terminal size, I get longer paths:


$ git format-patch -2 -v3 --stat=80 > /dev/null; cat v3-0000-cover-letter.patch | tail -6
Documentation/admin-guide/mm/memory-hotplug.rst | 800 ++++++++++++++----------
1 file changed, 455 insertions(+), 345 deletions(-)

(maybe my awesome-wm + xterm setup confuses git, or there is a
BUG somewhere in my software stack)

--
Thanks,

David / dhildenb

2021-07-01 15:31:18

by David Hildenbrand

[permalink] [raw]
Subject: Re: [PATCH v3 0/2] memory-hotplug.rst: complete admin-guide overhaul

On 09.06.21 09:57, David Hildenbrand wrote:
> This is v3 of the memory hot(un)plug admin-guide overhaul.
>
> v2 -> v3:
> - Added ACKs and RBs (thanks!)
> - s/aarch64/arm64/
> - Refine error handling when onlining/offlining
> - s/memory hotplug/memory offlining/ in the vmemmap optimization section
> for huge pages
>
> v1 -> v2:
> - Added "memory-hotplug.rst: remove locking details from admin-guide"
> - Incorporated all feedback from Mike and Michal (thanks!)
> - Compressed some lines to make full use of 80 chars.
> - Added details regarding 64bit/supported archs to the introduction.
> - Added KASAN to the list of sizing considerations.
>
> David Hildenbrand (2):
> memory-hotplug.rst: remove locking details from admin-guide
> memory-hotplug.rst: complete admin-guide overhaul
>
> .../admin-guide/mm/memory-hotplug.rst | 800 ++++++++++--------
> 1 file changed, 455 insertions(+), 345 deletions(-)
>

Andrew,

are you planning on picking+sending this for this cycle, or do you
prefer to let this doc update rest for a little bit longer?

I can spot that mmotm still contains v1.

Thanks!

--
Thanks,

David / dhildenb

2021-07-06 22:20:41

by Andrew Morton

[permalink] [raw]
Subject: Re: [PATCH v3 0/2] memory-hotplug.rst: complete admin-guide overhaul

On Thu, 1 Jul 2021 17:30:13 +0200 David Hildenbrand <[email protected]> wrote:

> On 09.06.21 09:57, David Hildenbrand wrote:
> > This is v3 of the memory hot(un)plug admin-guide overhaul.
> >
> > v2 -> v3:
> > - Added ACKs and RBs (thanks!)
> > - s/aarch64/arm64/
> > - Refine error handling when onlining/offlining
> > - s/memory hotplug/memory offlining/ in the vmemmap optimization section
> > for huge pages
> >
> > v1 -> v2:
> > - Added "memory-hotplug.rst: remove locking details from admin-guide"
> > - Incorporated all feedback from Mike and Michal (thanks!)
> > - Compressed some lines to make full use of 80 chars.
> > - Added details regarding 64bit/supported archs to the introduction.
> > - Added KASAN to the list of sizing considerations.
> >
> > David Hildenbrand (2):
> > memory-hotplug.rst: remove locking details from admin-guide
> > memory-hotplug.rst: complete admin-guide overhaul
> >
> > .../admin-guide/mm/memory-hotplug.rst | 800 ++++++++++--------
> > 1 file changed, 455 insertions(+), 345 deletions(-)
> >
>
> Andrew,
>
> are you planning on picking+sending this for this cycle, or do you
> prefer to let this doc update rest for a little bit longer?
>
> I can spot that mmotm still contains v1.

Seems that whenever I take a documentation patch, Jon pops up and takes
it as well. Except this time ;)

Please resend whatever's needed against current mainline?