From: David Hildenbrand <david@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Michal Hocko <mhocko@kernel.org>,
Michal Such?nek <msuchanek@suse.de>,
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>,
linuxppc-dev@lists.ozlabs.org, Christopher Lameter <cl@linux.com>,
Vlastimil Babka <vbabka@suse.cz>, Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH v5 3/3] mm/page_alloc: Keep memoryless cpuless node 0 offline
Date: Fri, 7 Aug 2020 08:58:09 +0200 [thread overview]
Message-ID: <5688b358-36bc-ccf0-d24b-a65375a9f3c3@redhat.com> (raw)
In-Reply-To: <20200806213211.6a6a56037fe771836e5abbe9@linux-foundation.org>
On 07.08.20 06:32, Andrew Morton wrote:
> On Fri, 3 Jul 2020 18:28:23 +0530 Srikar Dronamraju <srikar@linux.vnet.ibm.com> wrote:
>
>>> The memory hotplug changes that somehow because you can hotremove numa
>>> nodes and therefore make the nodemask sparse but that is not a common
>>> case. I am not sure what would happen if a completely new node was added
>>> and its corresponding node was already used by the renumbered one
>>> though. It would likely conflate the two I am afraid. But I am not sure
>>> this is really possible with x86 and a lack of a bug report would
>>> suggest that nobody is doing that at least.
>>>
>>
>> JFYI,
>> Satheesh copied in this mailchain had opened a bug a year on crash with vcpu
>> hotplug on memoryless node.
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=202187
>
> So... do we merge this patch or not? Seems that the overall view is
> "risky but nobody is likely to do anything better any time soon"?
I recall the issue Michal saw was "fix powerpc" vs. "break other
architectures". @Michal how should we proceed? At least x86-64 won't be
affected IIUC.
--
Thanks,
David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Gautham R Shenoy <ego@linux.vnet.ibm.com>,
Andi Kleen <ak@linux.intel.com>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Michal Hocko <mhocko@kernel.org>,
linux-mm@kvack.org,
Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>,
Mel Gorman <mgorman@suse.de>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Christopher Lameter <cl@linux.com>,
Michal Such?nek <msuchanek@suse.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH v5 3/3] mm/page_alloc: Keep memoryless cpuless node 0 offline
Date: Fri, 7 Aug 2020 08:58:09 +0200 [thread overview]
Message-ID: <5688b358-36bc-ccf0-d24b-a65375a9f3c3@redhat.com> (raw)
In-Reply-To: <20200806213211.6a6a56037fe771836e5abbe9@linux-foundation.org>
On 07.08.20 06:32, Andrew Morton wrote:
> On Fri, 3 Jul 2020 18:28:23 +0530 Srikar Dronamraju <srikar@linux.vnet.ibm.com> wrote:
>
>>> The memory hotplug changes that somehow because you can hotremove numa
>>> nodes and therefore make the nodemask sparse but that is not a common
>>> case. I am not sure what would happen if a completely new node was added
>>> and its corresponding node was already used by the renumbered one
>>> though. It would likely conflate the two I am afraid. But I am not sure
>>> this is really possible with x86 and a lack of a bug report would
>>> suggest that nobody is doing that at least.
>>>
>>
>> JFYI,
>> Satheesh copied in this mailchain had opened a bug a year on crash with vcpu
>> hotplug on memoryless node.
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=202187
>
> So... do we merge this patch or not? Seems that the overall view is
> "risky but nobody is likely to do anything better any time soon"?
I recall the issue Michal saw was "fix powerpc" vs. "break other
architectures". @Michal how should we proceed? At least x86-64 won't be
affected IIUC.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2020-08-07 6:58 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
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 [this message]
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=5688b358-36bc-ccf0-d24b-a65375a9f3c3@redhat.com \
--to=david@redhat.com \
--cc=ak@linux.intel.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=msuchanek@suse.de \
--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.