From: Baoquan He <bhe@redhat.com>
To: Mike Rapoport <rppt@linux.ibm.com>, Michal Hocko <mhocko@kernel.org>
Cc: Hoan Tran <Hoan@os.amperecomputing.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Oscar Salvador <osalvador@suse.de>,
Pavel Tatashin <pavel.tatashin@microsoft.com>,
Alexander Duyck <alexander.h.duyck@linux.intel.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
"David S. Miller" <davem@davemloft.net>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
sparclinux@vger.kernel.org, x86@kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
lho@amperecomputing.com, mmorana@amperecomputing.com
Subject: Re: [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA)
Date: Thu, 9 Apr 2020 22:41:19 +0800 [thread overview]
Message-ID: <20200409144119.GE2129@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20200402080144.GK22681@dhcp22.suse.cz>
On 04/02/20 at 10:01am, Michal Hocko wrote:
> On Wed 01-04-20 10:51:55, Mike Rapoport wrote:
> > Hi,
> >
> > On Wed, Apr 01, 2020 at 01:42:27PM +0800, Baoquan He wrote:
> [...]
> > > From above information, we can remove HAVE_MEMBLOCK_NODE_MAP, and
> > > replace it with CONFIG_NUMA. That sounds more sensible to store nid into
> > > memblock when NUMA support is enabled.
> >
> > Replacing CONFIG_HAVE_MEMBLOCK_NODE_MAP with CONFIG_NUMA will work, but
> > this will not help cleaning up the whole node/zone initialization mess and
> > we'll be stuck with two implementations.
>
> Yeah, this is far from optimal.
>
> > The overhead of enabling HAVE_MEMBLOCK_NODE_MAP is only for init time as
> > most architectures will anyway discard the entire memblock, so having it in
> > a UMA arch won't be a problem. The only exception is arm that uses
> > memblock for pfn_valid(), here we may also think about a solution to
> > compensate the addition of nid to the memblock structures.
>
> Well, we can make memblock_region->nid defined only for CONFIG_NUMA.
> memblock_get_region_node would then unconditionally return 0 on UMA.
> Essentially the same way we do NUMA for other MM code. I only see few
> direct usage of region->nid.
Checked code again, seems HAVE_MEMBLOCK_NODE_MAP is selected directly in
all ARCHes which support it. Means HAVE_MEMBLOCK_NODE_MAP is enabled by
default on those ARCHes, and has no dependency on CONFIG_NUMA at all.
E.g on x86, it just calls free_area_init_nodes() in generic code path,
while free_area_init_nodes() is defined in CONFIG_HAVE_MEMBLOCK_NODE_MAP
ifdeffery scope. So I tend to agree with Mike to remove
HAVE_MEMBLOCK_NODE_MAP firstly on all ARCHes. We can check if it's worth
only defining memblock_region->nid for CONFIG_NUMA case after
HAVE_MEMBLOCK_NODE_MAP is removed.
config X86
def_bool y
...
select HAVE_MEMBLOCK_NODE_MAP
...
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Mike Rapoport <rppt@linux.ibm.com>, Michal Hocko <mhocko@kernel.org>
Cc: mmorana@amperecomputing.com,
Catalin Marinas <catalin.marinas@arm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
Paul Mackerras <paulus@samba.org>,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org,
Alexander Duyck <alexander.h.duyck@linux.intel.com>,
linux-s390@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>,
x86@kernel.org, Christian Borntraeger <borntraeger@de.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Hoan Tran <Hoan@os.amperecomputing.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Pavel Tatashin <pavel.tatashin@microsoft.com>,
lho@amperecomputing.com, Vasily Gorbik <gor@linux.ibm.com>,
Vlastimil Babka <vbabka@suse.cz>,
Will Deacon <will.deacon@arm.com>, Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Oscar Salvador <osalvador@suse.de>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_
Date: Thu, 09 Apr 2020 14:41:19 +0000 [thread overview]
Message-ID: <20200409144119.GE2129@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20200402080144.GK22681@dhcp22.suse.cz>
On 04/02/20 at 10:01am, Michal Hocko wrote:
> On Wed 01-04-20 10:51:55, Mike Rapoport wrote:
> > Hi,
> >
> > On Wed, Apr 01, 2020 at 01:42:27PM +0800, Baoquan He wrote:
> [...]
> > > From above information, we can remove HAVE_MEMBLOCK_NODE_MAP, and
> > > replace it with CONFIG_NUMA. That sounds more sensible to store nid into
> > > memblock when NUMA support is enabled.
> >
> > Replacing CONFIG_HAVE_MEMBLOCK_NODE_MAP with CONFIG_NUMA will work, but
> > this will not help cleaning up the whole node/zone initialization mess and
> > we'll be stuck with two implementations.
>
> Yeah, this is far from optimal.
>
> > The overhead of enabling HAVE_MEMBLOCK_NODE_MAP is only for init time as
> > most architectures will anyway discard the entire memblock, so having it in
> > a UMA arch won't be a problem. The only exception is arm that uses
> > memblock for pfn_valid(), here we may also think about a solution to
> > compensate the addition of nid to the memblock structures.
>
> Well, we can make memblock_region->nid defined only for CONFIG_NUMA.
> memblock_get_region_node would then unconditionally return 0 on UMA.
> Essentially the same way we do NUMA for other MM code. I only see few
> direct usage of region->nid.
Checked code again, seems HAVE_MEMBLOCK_NODE_MAP is selected directly in
all ARCHes which support it. Means HAVE_MEMBLOCK_NODE_MAP is enabled by
default on those ARCHes, and has no dependency on CONFIG_NUMA at all.
E.g on x86, it just calls free_area_init_nodes() in generic code path,
while free_area_init_nodes() is defined in CONFIG_HAVE_MEMBLOCK_NODE_MAP
ifdeffery scope. So I tend to agree with Mike to remove
HAVE_MEMBLOCK_NODE_MAP firstly on all ARCHes. We can check if it's worth
only defining memblock_region->nid for CONFIG_NUMA case after
HAVE_MEMBLOCK_NODE_MAP is removed.
config X86
def_bool y
...
select HAVE_MEMBLOCK_NODE_MAP
...
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Mike Rapoport <rppt@linux.ibm.com>, Michal Hocko <mhocko@kernel.org>
Cc: mmorana@amperecomputing.com,
Catalin Marinas <catalin.marinas@arm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
Paul Mackerras <paulus@samba.org>,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org,
Alexander Duyck <alexander.h.duyck@linux.intel.com>,
linux-s390@vger.kernel.org, x86@kernel.org,
Christian Borntraeger <borntraeger@de.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Hoan Tran <Hoan@os.amperecomputing.com>,
Pavel Tatashin <pavel.tatashin@microsoft.com>,
lho@amperecomputing.com, Vasily Gorbik <gor@linux.ibm.com>,
Vlastimil Babka <vbabka@suse.cz>,
Will Deacon <will.deacon@arm.com>, Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Oscar Salvador <osalvador@suse.de>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA)
Date: Thu, 9 Apr 2020 22:41:19 +0800 [thread overview]
Message-ID: <20200409144119.GE2129@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20200402080144.GK22681@dhcp22.suse.cz>
On 04/02/20 at 10:01am, Michal Hocko wrote:
> On Wed 01-04-20 10:51:55, Mike Rapoport wrote:
> > Hi,
> >
> > On Wed, Apr 01, 2020 at 01:42:27PM +0800, Baoquan He wrote:
> [...]
> > > From above information, we can remove HAVE_MEMBLOCK_NODE_MAP, and
> > > replace it with CONFIG_NUMA. That sounds more sensible to store nid into
> > > memblock when NUMA support is enabled.
> >
> > Replacing CONFIG_HAVE_MEMBLOCK_NODE_MAP with CONFIG_NUMA will work, but
> > this will not help cleaning up the whole node/zone initialization mess and
> > we'll be stuck with two implementations.
>
> Yeah, this is far from optimal.
>
> > The overhead of enabling HAVE_MEMBLOCK_NODE_MAP is only for init time as
> > most architectures will anyway discard the entire memblock, so having it in
> > a UMA arch won't be a problem. The only exception is arm that uses
> > memblock for pfn_valid(), here we may also think about a solution to
> > compensate the addition of nid to the memblock structures.
>
> Well, we can make memblock_region->nid defined only for CONFIG_NUMA.
> memblock_get_region_node would then unconditionally return 0 on UMA.
> Essentially the same way we do NUMA for other MM code. I only see few
> direct usage of region->nid.
Checked code again, seems HAVE_MEMBLOCK_NODE_MAP is selected directly in
all ARCHes which support it. Means HAVE_MEMBLOCK_NODE_MAP is enabled by
default on those ARCHes, and has no dependency on CONFIG_NUMA at all.
E.g on x86, it just calls free_area_init_nodes() in generic code path,
while free_area_init_nodes() is defined in CONFIG_HAVE_MEMBLOCK_NODE_MAP
ifdeffery scope. So I tend to agree with Mike to remove
HAVE_MEMBLOCK_NODE_MAP firstly on all ARCHes. We can check if it's worth
only defining memblock_region->nid for CONFIG_NUMA case after
HAVE_MEMBLOCK_NODE_MAP is removed.
config X86
def_bool y
...
select HAVE_MEMBLOCK_NODE_MAP
...
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Mike Rapoport <rppt@linux.ibm.com>, Michal Hocko <mhocko@kernel.org>
Cc: mmorana@amperecomputing.com,
Catalin Marinas <catalin.marinas@arm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
Paul Mackerras <paulus@samba.org>,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org,
Alexander Duyck <alexander.h.duyck@linux.intel.com>,
linux-s390@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>,
x86@kernel.org, Christian Borntraeger <borntraeger@de.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Hoan Tran <Hoan@os.amperecomputing.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Pavel Tatashin <pavel.tatashin@microsoft.com>,
lho@amperecomputing.com, Vasily Gorbik <gor@linux.ibm.com>,
Vlastimil Babka <vbabka@suse.cz>,
Will Deacon <will.deacon@arm.com>, Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Oscar Salvador <osalvador@suse.de>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA)
Date: Thu, 9 Apr 2020 22:41:19 +0800 [thread overview]
Message-ID: <20200409144119.GE2129@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20200402080144.GK22681@dhcp22.suse.cz>
On 04/02/20 at 10:01am, Michal Hocko wrote:
> On Wed 01-04-20 10:51:55, Mike Rapoport wrote:
> > Hi,
> >
> > On Wed, Apr 01, 2020 at 01:42:27PM +0800, Baoquan He wrote:
> [...]
> > > From above information, we can remove HAVE_MEMBLOCK_NODE_MAP, and
> > > replace it with CONFIG_NUMA. That sounds more sensible to store nid into
> > > memblock when NUMA support is enabled.
> >
> > Replacing CONFIG_HAVE_MEMBLOCK_NODE_MAP with CONFIG_NUMA will work, but
> > this will not help cleaning up the whole node/zone initialization mess and
> > we'll be stuck with two implementations.
>
> Yeah, this is far from optimal.
>
> > The overhead of enabling HAVE_MEMBLOCK_NODE_MAP is only for init time as
> > most architectures will anyway discard the entire memblock, so having it in
> > a UMA arch won't be a problem. The only exception is arm that uses
> > memblock for pfn_valid(), here we may also think about a solution to
> > compensate the addition of nid to the memblock structures.
>
> Well, we can make memblock_region->nid defined only for CONFIG_NUMA.
> memblock_get_region_node would then unconditionally return 0 on UMA.
> Essentially the same way we do NUMA for other MM code. I only see few
> direct usage of region->nid.
Checked code again, seems HAVE_MEMBLOCK_NODE_MAP is selected directly in
all ARCHes which support it. Means HAVE_MEMBLOCK_NODE_MAP is enabled by
default on those ARCHes, and has no dependency on CONFIG_NUMA at all.
E.g on x86, it just calls free_area_init_nodes() in generic code path,
while free_area_init_nodes() is defined in CONFIG_HAVE_MEMBLOCK_NODE_MAP
ifdeffery scope. So I tend to agree with Mike to remove
HAVE_MEMBLOCK_NODE_MAP firstly on all ARCHes. We can check if it's worth
only defining memblock_region->nid for CONFIG_NUMA case after
HAVE_MEMBLOCK_NODE_MAP is removed.
config X86
def_bool y
...
select HAVE_MEMBLOCK_NODE_MAP
...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-04-09 14:41 UTC|newest]
Thread overview: 156+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-28 18:31 [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` [PATCH v3 1/5] " Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` [PATCH v3 2/5] powerpc: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` [PATCH v3 3/5] x86: " Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` [PATCH v3 4/5] sparc: " Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` [PATCH v3 5/5] s390: " Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-28 18:31 ` Hoan Tran
2020-03-29 0:19 ` [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA Baoquan He
2020-03-29 0:19 ` Baoquan He
2020-03-29 0:19 ` Baoquan He
2020-03-29 0:19 ` Baoquan He
2020-03-30 7:44 ` Michal Hocko
2020-03-30 7:44 ` Michal Hocko
2020-03-30 7:44 ` Michal Hocko
2020-03-30 7:44 ` Michal Hocko
2020-03-30 8:04 ` Baoquan He
2020-03-30 8:04 ` Baoquan He
2020-03-30 8:04 ` Baoquan He
2020-03-30 8:04 ` Baoquan He
2020-03-30 7:42 ` Michal Hocko
2020-03-30 7:42 ` Michal Hocko
2020-03-30 7:42 ` Michal Hocko
2020-03-30 7:42 ` Michal Hocko
2020-03-30 8:16 ` Baoquan He
2020-03-30 8:16 ` Baoquan He
2020-03-30 8:16 ` Baoquan He
2020-03-30 8:16 ` Baoquan He
2020-03-30 8:28 ` Baoquan He
2020-03-30 8:28 ` Baoquan He
2020-03-30 8:28 ` Baoquan He
2020-03-30 8:28 ` Baoquan He
2020-03-30 9:21 ` Mike Rapoport
2020-03-30 9:21 ` Mike Rapoport
2020-03-30 9:21 ` Mike Rapoport
2020-03-30 9:21 ` Mike Rapoport
2020-03-30 9:58 ` Michal Hocko
2020-03-30 9:58 ` Michal Hocko
2020-03-30 9:58 ` Michal Hocko
2020-03-30 9:58 ` Michal Hocko
2020-03-30 10:26 ` Mike Rapoport
2020-03-30 10:26 ` Mike Rapoport
2020-03-30 10:26 ` Mike Rapoport
2020-03-30 10:26 ` Mike Rapoport
2020-03-30 10:43 ` Baoquan He
2020-03-30 10:43 ` Baoquan He
2020-03-30 10:43 ` Baoquan He
2020-03-30 10:43 ` Baoquan He
2020-03-31 21:56 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA) Mike Rapoport
2020-03-31 21:56 ` Mike Rapoport
2020-03-31 21:56 ` Mike Rapoport
2020-03-31 21:56 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODE Mike Rapoport
2020-04-01 5:42 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA) Baoquan He
2020-04-01 5:42 ` Baoquan He
2020-04-01 5:42 ` Baoquan He
2020-04-01 5:42 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_ Baoquan He
2020-04-01 7:51 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA) Mike Rapoport
2020-04-01 7:51 ` Mike Rapoport
2020-04-01 7:51 ` Mike Rapoport
2020-04-01 7:51 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_ Mike Rapoport
2020-04-02 8:01 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA) Michal Hocko
2020-04-02 8:01 ` Michal Hocko
2020-04-02 8:01 ` Michal Hocko
2020-04-02 8:01 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_ Michal Hocko
2020-04-09 14:41 ` Baoquan He [this message]
2020-04-09 14:41 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA) Baoquan He
2020-04-09 14:41 ` Baoquan He
2020-04-09 14:41 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_ Baoquan He
2020-04-09 15:33 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA) Michal Hocko
2020-04-09 15:33 ` Michal Hocko
2020-04-09 15:33 ` Michal Hocko
2020-04-09 15:33 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_ Michal Hocko
2020-04-10 6:46 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA) Baoquan He
2020-04-10 6:46 ` Baoquan He
2020-04-10 6:46 ` Baoquan He
2020-04-10 6:46 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_ Baoquan He
2020-03-30 9:26 ` [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA Baoquan He
2020-03-30 9:26 ` Baoquan He
2020-03-30 9:26 ` Baoquan He
2020-03-30 9:26 ` Baoquan He
2020-03-30 17:51 ` Mike Rapoport
2020-03-30 17:51 ` Mike Rapoport
2020-03-30 17:51 ` Mike Rapoport
2020-03-30 17:51 ` Mike Rapoport
2020-03-30 18:23 ` Michal Hocko
2020-03-30 18:23 ` Michal Hocko
2020-03-30 18:23 ` Michal Hocko
2020-03-30 18:23 ` Michal Hocko
2020-03-31 8:14 ` Mike Rapoport
2020-03-31 8:14 ` Mike Rapoport
2020-03-31 8:14 ` Mike Rapoport
2020-03-31 8:14 ` Mike Rapoport
2020-03-31 8:55 ` Michal Hocko
2020-03-31 8:55 ` Michal Hocko
2020-03-31 8:55 ` Michal Hocko
2020-03-31 8:55 ` Michal Hocko
2020-03-31 14:03 ` Baoquan He
2020-03-31 14:03 ` Baoquan He
2020-03-31 14:03 ` Baoquan He
2020-03-31 14:03 ` Baoquan He
2020-03-31 14:21 ` Michal Hocko
2020-03-31 14:21 ` Michal Hocko
2020-03-31 14:21 ` Michal Hocko
2020-03-31 14:21 ` Michal Hocko
2020-03-31 14:31 ` Baoquan He
2020-03-31 14:31 ` Baoquan He
2020-03-31 14:31 ` Baoquan He
2020-03-31 14:31 ` Baoquan He
2020-04-03 4:46 ` Hoan Tran
2020-04-03 4:46 ` Hoan Tran
2020-04-03 4:46 ` Hoan Tran
2020-04-03 4:46 ` Hoan Tran
2020-04-03 7:09 ` Baoquan He
2020-04-03 7:09 ` Baoquan He
2020-04-03 7:09 ` Baoquan He
2020-04-03 7:09 ` Baoquan He
2020-04-03 16:36 ` Hoan Tran
2020-04-03 16:36 ` Hoan Tran
2020-04-03 16:36 ` Hoan Tran
2020-04-03 16:36 ` Hoan Tran
2020-04-09 16:27 ` Mike Rapoport
2020-04-09 16:27 ` Mike Rapoport
2020-04-09 16:27 ` Mike Rapoport
2020-04-09 16:27 ` Mike Rapoport
2020-04-10 6:50 ` Baoquan He
2020-04-10 6:50 ` Baoquan He
2020-04-10 6:50 ` Baoquan He
2020-04-10 6:50 ` Baoquan He
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=20200409144119.GE2129@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=Hoan@os.amperecomputing.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@linux.intel.com \
--cc=benh@kernel.crashing.org \
--cc=borntraeger@de.ibm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=gor@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=lho@amperecomputing.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhocko@kernel.org \
--cc=mingo@redhat.com \
--cc=mmorana@amperecomputing.com \
--cc=mpe@ellerman.id.au \
--cc=osalvador@suse.de \
--cc=paulus@samba.org \
--cc=pavel.tatashin@microsoft.com \
--cc=rppt@linux.ibm.com \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
/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.