From: Baoquan He <bhe@redhat.com>
To: 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>,
Mike Rapoport <rppt@linux.ibm.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 v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA
Date: Mon, 30 Mar 2020 16:04:56 +0800 [thread overview]
Message-ID: <20200330080456.GJ9942@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20200330074426.GB14243@dhcp22.suse.cz>
On 03/30/20 at 09:44am, Michal Hocko wrote:
> On Sun 29-03-20 08:19:24, Baoquan He wrote:
> > On 03/28/20 at 11:31am, Hoan Tran wrote:
> > > In NUMA layout which nodes have memory ranges that span across other nodes,
> > > the mm driver can detect the memory node id incorrectly.
> > >
> > > For example, with layout below
> > > Node 0 address: 0000 xxxx 0000 xxxx
> > > Node 1 address: xxxx 1111 xxxx 1111
> >
> > Sorry, I read this example several times, but still don't get what it
> > means. Can it be given with real hex number address as an exmaple? I
> > mean just using the memory layout you have seen from some systems. The
> > change looks interesting though.
>
> Does this make it more clear?
> physical address range and its node associaion
> [0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1]
I later read it again, have got what Hoan is trying to say, thanks.
I think the change in this patchset makes sense, still have some concern
though, let me add comment in other thread.
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: 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,
Mike Rapoport <rppt@linux.ibm.com>,
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 v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA
Date: Mon, 30 Mar 2020 16:04:56 +0800 [thread overview]
Message-ID: <20200330080456.GJ9942@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20200330074426.GB14243@dhcp22.suse.cz>
On 03/30/20 at 09:44am, Michal Hocko wrote:
> On Sun 29-03-20 08:19:24, Baoquan He wrote:
> > On 03/28/20 at 11:31am, Hoan Tran wrote:
> > > In NUMA layout which nodes have memory ranges that span across other nodes,
> > > the mm driver can detect the memory node id incorrectly.
> > >
> > > For example, with layout below
> > > Node 0 address: 0000 xxxx 0000 xxxx
> > > Node 1 address: xxxx 1111 xxxx 1111
> >
> > Sorry, I read this example several times, but still don't get what it
> > means. Can it be given with real hex number address as an exmaple? I
> > mean just using the memory layout you have seen from some systems. The
> > change looks interesting though.
>
> Does this make it more clear?
> physical address range and its node associaion
> [0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1]
I later read it again, have got what Hoan is trying to say, thanks.
I think the change in this patchset makes sense, still have some concern
though, let me add comment in other thread.
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: 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, Mike Rapoport <rppt@linux.ibm.com>,
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 v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA
Date: Mon, 30 Mar 2020 08:04:56 +0000 [thread overview]
Message-ID: <20200330080456.GJ9942@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20200330074426.GB14243@dhcp22.suse.cz>
On 03/30/20 at 09:44am, Michal Hocko wrote:
> On Sun 29-03-20 08:19:24, Baoquan He wrote:
> > On 03/28/20 at 11:31am, Hoan Tran wrote:
> > > In NUMA layout which nodes have memory ranges that span across other nodes,
> > > the mm driver can detect the memory node id incorrectly.
> > >
> > > For example, with layout below
> > > Node 0 address: 0000 xxxx 0000 xxxx
> > > Node 1 address: xxxx 1111 xxxx 1111
> >
> > Sorry, I read this example several times, but still don't get what it
> > means. Can it be given with real hex number address as an exmaple? I
> > mean just using the memory layout you have seen from some systems. The
> > change looks interesting though.
>
> Does this make it more clear?
> physical address range and its node associaion
> [0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1]
I later read it again, have got what Hoan is trying to say, thanks.
I think the change in this patchset makes sense, still have some concern
though, let me add comment in other thread.
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: 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, Mike Rapoport <rppt@linux.ibm.com>,
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 v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA
Date: Mon, 30 Mar 2020 16:04:56 +0800 [thread overview]
Message-ID: <20200330080456.GJ9942@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20200330074426.GB14243@dhcp22.suse.cz>
On 03/30/20 at 09:44am, Michal Hocko wrote:
> On Sun 29-03-20 08:19:24, Baoquan He wrote:
> > On 03/28/20 at 11:31am, Hoan Tran wrote:
> > > In NUMA layout which nodes have memory ranges that span across other nodes,
> > > the mm driver can detect the memory node id incorrectly.
> > >
> > > For example, with layout below
> > > Node 0 address: 0000 xxxx 0000 xxxx
> > > Node 1 address: xxxx 1111 xxxx 1111
> >
> > Sorry, I read this example several times, but still don't get what it
> > means. Can it be given with real hex number address as an exmaple? I
> > mean just using the memory layout you have seen from some systems. The
> > change looks interesting though.
>
> Does this make it more clear?
> physical address range and its node associaion
> [0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1]
I later read it again, have got what Hoan is trying to say, thanks.
I think the change in this patchset makes sense, still have some concern
though, let me add comment in other thread.
_______________________________________________
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-03-30 8:05 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 [this message]
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 ` [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODE 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_NODES_SPAN_OTHER_NODES by default for NUMA) Mike Rapoport
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 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 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-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-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-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-09 14:41 ` 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 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 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-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-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-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-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=20200330080456.GJ9942@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.