linux-kernel - Re: [PATCH 2/2] mm, memory_hotplug: remove zone restrictions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170706065649.GC29724@dhcp22.suse.cz>
Date:   Thu, 6 Jul 2017 08:56:50 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Wei Yang <richard.weiyang@...il.com>
Cc:     Linux-MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mel Gorman <mgorman@...e.de>, Vlastimil Babka <vbabka@...e.cz>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Reza Arbab <arbab@...ux.vnet.ibm.com>,
        Yasuaki Ishimatsu <yasu.isimatu@...il.com>,
        Xishi Qiu <qiuxishi@...wei.com>,
        Kani Toshimitsu <toshi.kani@....com>, slaoub@...il.com,
        Joonsoo Kim <js1304@...il.com>,
        Daniel Kiper <daniel.kiper@...cle.com>,
        Igor Mammedov <imammedo@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] mm, memory_hotplug: remove zone restrictions

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@...nel.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