Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1681931 > unrolled thread
| Started by | Wei Yang <richard.weiyang@gmail.com> |
|---|---|
| First post | 2017-07-06 01:20 +0200 |
| Last post | 2017-07-07 14:50 +0200 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH 2/2] mm, memory_hotplug: remove zone restrictions Wei Yang <richard.weiyang@gmail.com> - 2017-07-06 01:20 +0200
Re: [PATCH 2/2] mm, memory_hotplug: remove zone restrictions Michal Hocko <mhocko@kernel.org> - 2017-07-06 09:00 +0200
Re: [PATCH 2/2] mm, memory_hotplug: remove zone restrictions Wei Yang <richard.weiyang@gmail.com> - 2017-07-07 10:40 +0200
Re: [PATCH 2/2] mm, memory_hotplug: remove zone restrictions Michal Hocko <mhocko@kernel.org> - 2017-07-07 14:50 +0200
| From | Wei Yang <richard.weiyang@gmail.com> |
|---|---|
| Date | 2017-07-06 01:20 +0200 |
| Subject | Re: [PATCH 2/2] mm, memory_hotplug: remove zone restrictions |
| Message-ID | <u01Kq-4tO-13@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Jun 30, 2017 at 01:01:18PM +0200, Michal Hocko wrote:
>On Fri 30-06-17 11:55:45, Michal Hocko wrote:
>> On Fri 30-06-17 17:39:56, Wei Yang wrote:
>> > On Fri, Jun 30, 2017 at 4:39 PM, Michal Hocko <mhocko@kernel.org> wrote:
>> [...]
>> > > yes and to be honest I do not plan to fix it unless somebody has a real
>> > > life usecase for it. Now that we allow explicit onlininig type anywhere
>> > > it seems like a reasonable behavior and this will allow us to remove
>> > > quite some code which is always a good deal wrt longterm maintenance.
>> > >
>> >
>> > hmm... the statistics displayed in /proc/zoneinfo would be meaningless
>> > for zone_normal and zone_movable.
>>
>> Why would they be meaningless? Counters will always reflect the actual
>> use - if not then it is a bug. And wrt to zone description what is
>> meaningless about
>> memory34/valid_zones:Normal
>> memory35/valid_zones:Normal Movable
>> memory36/valid_zones:Movable
>> memory37/valid_zones:Movable Normal
>> memory38/valid_zones:Movable Normal
>> memory39/valid_zones:Movable Normal
>> memory40/valid_zones:Normal
>> memory41/valid_zones:Movable
>>
>> And
>> Node 1, zone Normal
>> pages free 65465
>> min 156
>> low 221
>> high 286
>> spanned 229376
>> present 65536
>> managed 65536
>> [...]
>> start_pfn: 1114112
>> Node 1, zone Movable
>> pages free 65443
>> min 156
>> low 221
>> high 286
>> spanned 196608
>> present 65536
>> managed 65536
>> [...]
>> start_pfn: 1179648
>>
>> ranges are clearly defined as [start_pfn, start_pfn+managed] and managed
>
>errr, this should be [start_pfn, start_pfn + spanned] of course.
>
The spanned is not adjusted after offline, neither does start_pfn. For example,
even offline all the movable_zone range, we can still see the spanned.
Below is a result with a little changed kernel to show the start_pfn always.
The sequence is:
1. bootup
Node 0, zone Movable
spanned 65536
present 0
managed 0
start_pfn: 0
2. online movable 2 continuous memory_blocks
Node 0, zone Movable
spanned 65536
present 65536
managed 65536
start_pfn: 1310720
3. offline 2nd memory_blocks
Node 0, zone Movable
spanned 65536
present 32768
managed 32768
start_pfn: 1310720
4. offline 1st memory_blocks
Node 0, zone Movable
spanned 65536
present 0
managed 0
start_pfn: 1310720
So I am not sure this is still clearly defined?
>> matches the number of onlined pages (256MB).
>
>--
>Michal Hocko
>SUSE Labs
--
Wei Yang
Help you, Help me
[toc] | [next] | [standalone]
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2017-07-06 09:00 +0200 |
| Message-ID | <u08Vz-Sf-3@gated-at.bofh.it> |
| In reply to | #1681931 |
On Thu 06-07-17 07:16:49, Wei Yang wrote: > On Fri, Jun 30, 2017 at 01:01:18PM +0200, Michal Hocko wrote: > >On Fri 30-06-17 11:55:45, Michal Hocko wrote: > >> On Fri 30-06-17 17:39:56, Wei Yang wrote: > >> > On Fri, Jun 30, 2017 at 4:39 PM, Michal Hocko <mhocko@kernel.org> wrote: > >> [...] > >> > > yes and to be honest I do not plan to fix it unless somebody has a real > >> > > life usecase for it. Now that we allow explicit onlininig type anywhere > >> > > it seems like a reasonable behavior and this will allow us to remove > >> > > quite some code which is always a good deal wrt longterm maintenance. > >> > > > >> > > >> > hmm... the statistics displayed in /proc/zoneinfo would be meaningless > >> > for zone_normal and zone_movable. > >> > >> Why would they be meaningless? Counters will always reflect the actual > >> use - if not then it is a bug. And wrt to zone description what is > >> meaningless about > >> memory34/valid_zones:Normal > >> memory35/valid_zones:Normal Movable > >> memory36/valid_zones:Movable > >> memory37/valid_zones:Movable Normal > >> memory38/valid_zones:Movable Normal > >> memory39/valid_zones:Movable Normal > >> memory40/valid_zones:Normal > >> memory41/valid_zones:Movable > >> > >> And > >> Node 1, zone Normal > >> pages free 65465 > >> min 156 > >> low 221 > >> high 286 > >> spanned 229376 > >> present 65536 > >> managed 65536 > >> [...] > >> start_pfn: 1114112 > >> Node 1, zone Movable > >> pages free 65443 > >> min 156 > >> low 221 > >> high 286 > >> spanned 196608 > >> present 65536 > >> managed 65536 > >> [...] > >> start_pfn: 1179648 > >> > >> ranges are clearly defined as [start_pfn, start_pfn+managed] and managed > > > >errr, this should be [start_pfn, start_pfn + spanned] of course. > > > > The spanned is not adjusted after offline, neither does start_pfn. For example, > even offline all the movable_zone range, we can still see the spanned. Which is completely valid. Offline only changes present/managed. > Below is a result with a little changed kernel to show the start_pfn always. > The sequence is: > 1. bootup > > Node 0, zone Movable > spanned 65536 > present 0 > managed 0 > start_pfn: 0 > > 2. online movable 2 continuous memory_blocks > > Node 0, zone Movable > spanned 65536 > present 65536 > managed 65536 > start_pfn: 1310720 > > 3. offline 2nd memory_blocks > > Node 0, zone Movable > spanned 65536 > present 32768 > managed 32768 > start_pfn: 1310720 > > 4. offline 1st memory_blocks > > Node 0, zone Movable > spanned 65536 > present 0 > managed 0 > start_pfn: 1310720 > > So I am not sure this is still clearly defined? Could you be more specific what is not clearly defined? You have offlined all online memory blocks so present/managed is 0 while the spanned is unchanged because the zone is still defined in range [1310720, 1376256]. I also do not see how this is related with the discussed patch as there is no zone interleaving involved. -- Michal Hocko SUSE Labs
[toc] | [prev] | [next] | [standalone]
| From | Wei Yang <richard.weiyang@gmail.com> |
|---|---|
| Date | 2017-07-07 10:40 +0200 |
| Message-ID | <u0wXT-1kR-5@gated-at.bofh.it> |
| In reply to | #1682088 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Jul 06, 2017 at 08:56:50AM +0200, Michal Hocko wrote: >> Below is a result with a little changed kernel to show the start_pfn always. >> The sequence is: >> 1. bootup >> >> Node 0, zone Movable >> spanned 65536 >> present 0 >> managed 0 >> start_pfn: 0 >> >> 2. online movable 2 continuous memory_blocks >> >> Node 0, zone Movable >> spanned 65536 >> present 65536 >> managed 65536 >> start_pfn: 1310720 >> >> 3. offline 2nd memory_blocks >> >> Node 0, zone Movable >> spanned 65536 >> present 32768 >> managed 32768 >> start_pfn: 1310720 >> >> 4. offline 1st memory_blocks >> >> Node 0, zone Movable >> spanned 65536 >> present 0 >> managed 0 >> start_pfn: 1310720 >> >> So I am not sure this is still clearly defined? > >Could you be more specific what is not clearly defined? You have >offlined all online memory blocks so present/managed is 0 while the >spanned is unchanged because the zone is still defined in range >[1310720, 1376256]. > The zone is empty after remove these two memory blocks, while we still think it is defined in range [1310720, 1376256]. This is what I want to point. >I also do not see how this is related with the discussed patch as there >is no zone interleaving involved. I had a patch which fix the behavior, which means we can make sure the zone is empty after remove these two memory blocks. As you mentioned in the reply, http://www.spinics.net/lists/linux-mm/msg130230.html, I thought you would have this fixed in this cycle. While it looks we will still have this behavior in this cycle and looks no intend to fix this? >-- >Michal Hocko >SUSE Labs -- Wei Yang Help you, Help me
[toc] | [prev] | [next] | [standalone]
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2017-07-07 14:50 +0200 |
| Message-ID | <u0ARP-44v-1@gated-at.bofh.it> |
| In reply to | #1683022 |
On Fri 07-07-17 16:37:23, Wei Yang wrote: > On Thu, Jul 06, 2017 at 08:56:50AM +0200, Michal Hocko wrote: > >> Below is a result with a little changed kernel to show the start_pfn always. > >> The sequence is: > >> 1. bootup > >> > >> Node 0, zone Movable > >> spanned 65536 > >> present 0 > >> managed 0 > >> start_pfn: 0 > >> > >> 2. online movable 2 continuous memory_blocks > >> > >> Node 0, zone Movable > >> spanned 65536 > >> present 65536 > >> managed 65536 > >> start_pfn: 1310720 > >> > >> 3. offline 2nd memory_blocks > >> > >> Node 0, zone Movable > >> spanned 65536 > >> present 32768 > >> managed 32768 > >> start_pfn: 1310720 > >> > >> 4. offline 1st memory_blocks > >> > >> Node 0, zone Movable > >> spanned 65536 > >> present 0 > >> managed 0 > >> start_pfn: 1310720 > >> > >> So I am not sure this is still clearly defined? > > > >Could you be more specific what is not clearly defined? You have > >offlined all online memory blocks so present/managed is 0 while the > >spanned is unchanged because the zone is still defined in range > >[1310720, 1376256]. > > > > The zone is empty after remove these two memory blocks, while we still think > it is defined in range [1310720, 1376256]. Yes and present/managed shows that the zone is empty. It's range spans some range but there are no online pages. > This is what I want to point. As I've said several times already. This is somemething that _could_ be fixed but I would rather not to do so until there is a _readl_ usecase which would depend on it. Especially when we can online any memory block to the zone you like. We should really strive to reduce the amount of code rather than keep it just in case without anybody actually using it. -- Michal Hocko SUSE Labs
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web