2017-06-22 04:18:50

by Wei Yang

[permalink] [raw]
Subject: [PATCH] docs/memory-hotplug: adjust the explanation of valid_zones sysfs

After commit "mm, memory_hotplug: do not associate hotadded memory to zones
until online", the meaning of valid_zones is changed.

1. When the memory block is online, it returns the onlined zone name
2. We won't have "Movable Normal" case, because default_zone couldn't be
MOVABLE

This patch adjust the document according the code change.

Signed-off-by: Wei Yang <[email protected]>
---
Documentation/memory-hotplug.txt | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index 670f3ded0802..d85ceb53f52a 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -171,15 +171,15 @@ Under each memory block, you can see 5 files:
block is removable and a value of 0 indicates that
it is not removable. A memory block is removable only if
every section in the block is removable.
-'valid_zones' : read-only: designed to show which zones this memory block
- can be onlined to.
- The first column shows it's default zone.
+'valid_zones' : read-only: shows different information based on state.
+ When state is online, it is designed to show the
+ zone name this memory block is onlined to.
+ When state is offline, it is designed to show which zones
+ this memory block can be onlined to. The first column
+ shows it's default zone.
"memory6/valid_zones: Normal Movable" shows this memoryblock
can be onlined to ZONE_NORMAL by default and to ZONE_MOVABLE
by online_movable.
- "memory7/valid_zones: Movable Normal" shows this memoryblock
- can be onlined to ZONE_MOVABLE by default and to ZONE_NORMAL
- by online_kernel.

NOTE:
These directories/files appear after physical memory hotplug phase.
--
2.11.0


2017-06-22 18:21:18

by Michal Hocko

[permalink] [raw]
Subject: Re: [PATCH] docs/memory-hotplug: adjust the explanation of valid_zones sysfs

On Thu 22-06-17 12:18:44, Wei Yang wrote:
[...]
> -'valid_zones' : read-only: designed to show which zones this memory block
> - can be onlined to.
> - The first column shows it's default zone.
> +'valid_zones' : read-only: shows different information based on state.
> + When state is online, it is designed to show the
> + zone name this memory block is onlined to.
> + When state is offline, it is designed to show which zones
> + this memory block can be onlined to. The first column
> + shows it's default zone.

I do not think we really need to touch this. First of all the last
sentence is not really correct. The ordering of zones doesn't tell which
zone will be onlined by default. This is indeed a change of behavior of
my patch. I am just not sure anybody depends on that. I can fix it up
but again the old semantic was just awkward and I didn't feel like I
should keep it. Also I plan to change this behavior again with planned
patches. I would like to get rid of the non-overlapping zones
restriction so the wording would have to change again.

That being said, let's keep the wording as it is now.

Thanks!
--
Michal Hocko
SUSE Labs

2017-06-23 01:41:31

by Wei Yang

[permalink] [raw]
Subject: Re: [PATCH] docs/memory-hotplug: adjust the explanation of valid_zones sysfs

On Thu, Jun 22, 2017 at 08:21:14PM +0200, Michal Hocko wrote:
>On Thu 22-06-17 12:18:44, Wei Yang wrote:
>[...]
>> -'valid_zones' : read-only: designed to show which zones this memory block
>> - can be onlined to.
>> - The first column shows it's default zone.
>> +'valid_zones' : read-only: shows different information based on state.
>> + When state is online, it is designed to show the
>> + zone name this memory block is onlined to.
>> + When state is offline, it is designed to show which zones
>> + this memory block can be onlined to. The first column
>> + shows it's default zone.
>
>I do not think we really need to touch this. First of all the last
>sentence is not really correct. The ordering of zones doesn't tell which
>zone will be onlined by default. This is indeed a change of behavior of
>my patch. I am just not sure anybody depends on that. I can fix it up
>but again the old semantic was just awkward and I didn't feel like I
>should keep it. Also I plan to change this behavior again with planned
>patches. I would like to get rid of the non-overlapping zones
>restriction so the wording would have to change again.

Sure, look forward your up coming patches.

>
>That being said, let's keep the wording as it is now.
>
>Thanks!
>--
>Michal Hocko
>SUSE Labs

--
Wei Yang
Help you, Help me


Attachments:
(No filename) (1.33 kB)
signature.asc (819.00 B)
Download all attachments