All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Mel Gorman <mgorman@suse.de>,
	Vlastimil Babka <vbabka@suse.cz>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Christopher Lameter <cl@linux.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Gautham R Shenoy <ego@linux.vnet.ibm.com>,
	Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Subject: Re: [PATCH v5 3/3] mm/page_alloc: Keep memoryless cpuless node 0 offline
Date: Wed, 1 Jul 2020 12:15:54 +0200	[thread overview]
Message-ID: <184102af-ecf2-c834-db46-173ab2e66f51@redhat.com> (raw)
In-Reply-To: <20200701100442.GB17918@linux.vnet.ibm.com>

On 01.07.20 12:04, Srikar Dronamraju wrote:
> * Michal Hocko <mhocko@kernel.org> [2020-07-01 10:42:00]:
> 
>>
>>>
>>> 2. Also existence of dummy node also leads to inconsistent information. The
>>> number of online nodes is inconsistent with the information in the
>>> device-tree and resource-dump
>>>
>>> 3. When the dummy node is present, single node non-Numa systems end up showing
>>> up as NUMA systems and numa_balancing gets enabled. This will mean we take
>>> the hit from the unnecessary numa hinting faults.
>>
>> I have to say that I dislike the node online/offline state and directly
>> exporting that to the userspace. Users should only care whether the node
>> has memory/cpus. Numa nodes can be online without any memory. Just
>> offline all the present memory blocks but do not physically hot remove
>> them and you are in the same situation. If users are confused by an
>> output of tools like numactl -H then those could be updated and hide
>> nodes without any memory&cpus.
>>
>> The autonuma problem sounds interesting but again this patch doesn't
>> really solve the underlying problem because I strongly suspect that the
>> problem is still there when a numa node gets all its memory offline as
>> mentioned above.
>>
>> While I completely agree that making node 0 special is wrong, I have
>> still hard time to review this very simply looking patch because all the
>> numa initialization is so spread around that this might just blow up
>> at unexpected places. IIRC we have discussed testing in the previous
>> version and David has provided a way to emulate these configurations
>> on x86. Did you manage to use those instruction for additional testing
>> on other than ppc architectures?
>>
> 
> I have tried all the steps that David mentioned and reported back at
> https://lore.kernel.org/lkml/20200511174731.GD1961@linux.vnet.ibm.com/t/#u
> 
> As a summary, David's steps are still not creating a memoryless/cpuless on
> x86 VM.

Now, that is wrong. You get a memoryless/cpuless node, which is *not
online*. Once you hotplug some memory, it will switch online. Once you
remove memory, it will switch back offline.

-- 
Thanks,

David / dhildenb


WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	Michal Hocko <mhocko@kernel.org>
Cc: Gautham R Shenoy <ego@linux.vnet.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>,
	Mel Gorman <mgorman@suse.de>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org, Christopher Lameter <cl@linux.com>,
	Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH v5 3/3] mm/page_alloc: Keep memoryless cpuless node 0 offline
Date: Wed, 1 Jul 2020 12:15:54 +0200	[thread overview]
Message-ID: <184102af-ecf2-c834-db46-173ab2e66f51@redhat.com> (raw)
In-Reply-To: <20200701100442.GB17918@linux.vnet.ibm.com>

On 01.07.20 12:04, Srikar Dronamraju wrote:
> * Michal Hocko <mhocko@kernel.org> [2020-07-01 10:42:00]:
> 
>>
>>>
>>> 2. Also existence of dummy node also leads to inconsistent information. The
>>> number of online nodes is inconsistent with the information in the
>>> device-tree and resource-dump
>>>
>>> 3. When the dummy node is present, single node non-Numa systems end up showing
>>> up as NUMA systems and numa_balancing gets enabled. This will mean we take
>>> the hit from the unnecessary numa hinting faults.
>>
>> I have to say that I dislike the node online/offline state and directly
>> exporting that to the userspace. Users should only care whether the node
>> has memory/cpus. Numa nodes can be online without any memory. Just
>> offline all the present memory blocks but do not physically hot remove
>> them and you are in the same situation. If users are confused by an
>> output of tools like numactl -H then those could be updated and hide
>> nodes without any memory&cpus.
>>
>> The autonuma problem sounds interesting but again this patch doesn't
>> really solve the underlying problem because I strongly suspect that the
>> problem is still there when a numa node gets all its memory offline as
>> mentioned above.
>>
>> While I completely agree that making node 0 special is wrong, I have
>> still hard time to review this very simply looking patch because all the
>> numa initialization is so spread around that this might just blow up
>> at unexpected places. IIRC we have discussed testing in the previous
>> version and David has provided a way to emulate these configurations
>> on x86. Did you manage to use those instruction for additional testing
>> on other than ppc architectures?
>>
> 
> I have tried all the steps that David mentioned and reported back at
> https://lore.kernel.org/lkml/20200511174731.GD1961@linux.vnet.ibm.com/t/#u
> 
> As a summary, David's steps are still not creating a memoryless/cpuless on
> x86 VM.

Now, that is wrong. You get a memoryless/cpuless node, which is *not
online*. Once you hotplug some memory, it will switch online. Once you
remove memory, it will switch back offline.

-- 
Thanks,

David / dhildenb


  reply	other threads:[~2020-07-01 10:16 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24  9:28 [PATCH v5 0/3] Offline memoryless cpuless node 0 Srikar Dronamraju
2020-06-24  9:28 ` Srikar Dronamraju
2020-06-24  9:28 ` [PATCH v5 1/3] powerpc/numa: Set numa_node for all possible cpus Srikar Dronamraju
2020-06-24  9:28   ` Srikar Dronamraju
2020-06-24  9:48   ` Gautham R Shenoy
2020-06-24  9:48     ` Gautham R Shenoy
2020-06-24  9:28 ` [PATCH v5 2/3] powerpc/numa: Prefer node id queried from vphn Srikar Dronamraju
2020-06-24  9:28   ` Srikar Dronamraju
2020-06-24 10:29   ` Gautham R Shenoy
2020-06-24 10:29     ` Gautham R Shenoy
2020-06-24  9:28 ` [PATCH v5 3/3] mm/page_alloc: Keep memoryless cpuless node 0 offline Srikar Dronamraju
2020-06-24  9:28   ` Srikar Dronamraju
2020-06-29 14:58   ` Christopher Lameter
2020-06-29 14:58     ` Christopher Lameter
2020-06-29 14:58     ` Christopher Lameter
2020-06-30  4:01     ` Srikar Dronamraju
2020-06-30  4:01       ` Srikar Dronamraju
2020-07-01 12:23       ` Michal Hocko
2020-07-01 12:23         ` Michal Hocko
2020-07-01  8:42   ` Michal Hocko
2020-07-01  8:42     ` Michal Hocko
2020-07-01 10:04     ` Srikar Dronamraju
2020-07-01 10:04       ` Srikar Dronamraju
2020-07-01 10:15       ` David Hildenbrand [this message]
2020-07-01 10:15         ` David Hildenbrand
2020-07-01 11:01         ` Srikar Dronamraju
2020-07-01 11:01           ` Srikar Dronamraju
2020-07-01 11:06           ` David Hildenbrand
2020-07-01 11:06             ` David Hildenbrand
2020-07-01 11:30             ` David Hildenbrand
2020-07-01 11:30               ` David Hildenbrand
2020-07-01 12:21               ` Michal Hocko
2020-07-01 12:21                 ` Michal Hocko
2020-07-02  6:44                 ` Srikar Dronamraju
2020-07-02  6:44                   ` Srikar Dronamraju
2020-07-02  8:41                   ` Michal Hocko
2020-07-02  8:41                     ` Michal Hocko
2020-07-02 14:32                     ` Srikar Dronamraju
2020-07-02 14:32                       ` Srikar Dronamraju
2020-07-03  9:10                 ` Michal Suchánek
2020-07-03  9:10                   ` Michal Suchánek
2020-07-03  9:24                   ` Michal Hocko
2020-07-03  9:24                     ` Michal Hocko
2020-07-03 10:59                     ` Michal Hocko
2020-07-03 10:59                       ` Michal Hocko
2020-07-03 11:32                       ` David Hildenbrand
2020-07-03 11:32                         ` David Hildenbrand
2020-07-03 11:46                         ` Michal Hocko
2020-07-03 11:46                           ` Michal Hocko
2020-07-03 12:58                       ` Srikar Dronamraju
2020-07-03 12:58                         ` Srikar Dronamraju
2020-08-07  4:32                         ` Andrew Morton
2020-08-07  4:32                           ` Andrew Morton
2020-08-07  6:58                           ` David Hildenbrand
2020-08-07  6:58                             ` David Hildenbrand
2020-08-07 10:04                             ` Michal Suchánek
2020-08-07 10:04                               ` Michal Suchánek
2020-08-12  6:01                           ` Srikar Dronamraju
2020-08-12  6:01                             ` Srikar Dronamraju
2020-08-18  7:32                             ` David Hildenbrand
2020-08-18  7:32                               ` David Hildenbrand
2020-08-18  7:37                               ` Michal Hocko
2020-08-18  7:37                                 ` Michal Hocko
2020-08-18  7:49                                 ` Srikar Dronamraju
2020-08-18  7:49                                   ` Srikar Dronamraju
2020-07-06 16:08                     ` Andi Kleen
2020-07-06 16:08                       ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=184102af-ecf2-c834-db46-173ab2e66f51@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=ego@linux.vnet.ibm.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=sathnaga@linux.vnet.ibm.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.