From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
Mike Kravetz <mike.kravetz@oracle.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Dan Williams <dan.j.williams@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Mark Rutland <mark.rutland@arm.com>,
Mark Brown <broonie@kernel.org>,
Steven Price <Steven.Price@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Kees Cook <keescook@chromium.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Matthew Wilcox <willy@infradead.org>,
Sri Krishna chowdary <schowdary@nvidia.com>,
Dave Hansen <dave.hansen@intel.com>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
Michael Ellerman <mpe@ellerman.id.au>,
Paul Mackerras <paulus@samba.org>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
Vineet Gupta <vgupta@synopsys.com>,
James Hogan <jhogan@kernel.org>,
Paul Burton <paul.burton@mips.com>,
Ralf Baechle <ralf@linux-mips.org>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
Christophe Leroy <christophe.leroy@c-s.fr>,
David Rientjes <rientjes@google.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Oscar Salvador <osalvador@suse.de>,
Mel Gorman <mgorman@techsingularity.net>,
linux-snps-arc@lists.infradead.org, linux-mips@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V6 1/2] mm/page_alloc: Make alloc_gigantic_page() available for general use
Date: Tue, 15 Oct 2019 16:37:27 +0530 [thread overview]
Message-ID: <2d4e7b28-67bf-baf3-b8a0-a5b3a58e3b31@arm.com> (raw)
In-Reply-To: <20191015104521.GY317@dhcp22.suse.cz>
On 10/15/2019 04:15 PM, Michal Hocko wrote:
> On Tue 15-10-19 14:51:41, Anshuman Khandual wrote:
> [...]
>> +/**
>> + * alloc_gigantic_page_order() -- tries to allocate given order of pages
>> + * @order: allocation order (greater than MAX_ORDER)
>> + * @gfp_mask: GFP mask to use during compaction
>> + * @nid: allocation node
>> + * @nodemask: allocation nodemask
>> + *
>> + * This routine is an wrapper around alloc_contig_range() which scans over
>> + * all zones on an applicable zonelist to find a contiguous pfn range which
>> + * can the be allocated with alloc_contig_range(). This routine is intended
>> + * to be used for allocations greater than MAX_ORDER.
>> + *
>> + * Return: page on success or NULL on failure. On success a memory block
>> + * of 'order' starting with 'page' has been allocated successfully. Memory
>> + * allocated here needs to be freed with free_contig_range().
>> + */
>> +struct page *alloc_gigantic_page_order(unsigned int order, gfp_t gfp_mask,
>> + int nid, nodemask_t *nodemask)
>
> One of the objections when Mike has proposed a similar thing last year
> was that the interface shouldn't be order bases
> http://lkml.kernel.org/r/20180423000943.GO17484@dhcp22.suse.cz
>
> Order based API makes sense for the buddy allocator but why should we
> restrict sizes like that for an allocator that is capable to allocate
> arbitrary page sized requests?
Fair enough, will change it. Anyways we calculate nr_pages from the order
argument at the very beginning.
WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
James Hogan <jhogan@kernel.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dave Hansen <dave.hansen@intel.com>,
Paul Mackerras <paulus@samba.org>,
sparclinux@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-s390@vger.kernel.org, x86@kernel.org,
Russell King - ARM Linux <linux@armlinux.org.uk>,
Matthew Wilcox <willy@infradead.org>,
Steven Price <Steven.Price@arm.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
David Rientjes <rientjes@google.com>,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Kees Cook <keescook@chromium.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
linuxppc-dev@lists.ozlabs.org, Mark Brown <broonie@kernel.org>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
Dan Williams <dan.j.williams@intel.com>,
Vlastimil Babka <vbabka@suse.cz>,
Oscar Salvador <osalvador@suse.de>,
Sri Krishna chowdary <schowdary@nvidia.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-mips@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
Paul Burton <paul.burton@mips.com>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
Vineet Gupta <vgupta@synopsys.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@techsingularity.net>,
"David S. Miller" <davem@davemloft.net>,
Mike Kravetz <mike.kravetz@oracle.com>
Subject: Re: [PATCH V6 1/2] mm/page_alloc: Make alloc_gigantic_page() available for general use
Date: Tue, 15 Oct 2019 16:37:27 +0530 [thread overview]
Message-ID: <2d4e7b28-67bf-baf3-b8a0-a5b3a58e3b31@arm.com> (raw)
In-Reply-To: <20191015104521.GY317@dhcp22.suse.cz>
On 10/15/2019 04:15 PM, Michal Hocko wrote:
> On Tue 15-10-19 14:51:41, Anshuman Khandual wrote:
> [...]
>> +/**
>> + * alloc_gigantic_page_order() -- tries to allocate given order of pages
>> + * @order: allocation order (greater than MAX_ORDER)
>> + * @gfp_mask: GFP mask to use during compaction
>> + * @nid: allocation node
>> + * @nodemask: allocation nodemask
>> + *
>> + * This routine is an wrapper around alloc_contig_range() which scans over
>> + * all zones on an applicable zonelist to find a contiguous pfn range which
>> + * can the be allocated with alloc_contig_range(). This routine is intended
>> + * to be used for allocations greater than MAX_ORDER.
>> + *
>> + * Return: page on success or NULL on failure. On success a memory block
>> + * of 'order' starting with 'page' has been allocated successfully. Memory
>> + * allocated here needs to be freed with free_contig_range().
>> + */
>> +struct page *alloc_gigantic_page_order(unsigned int order, gfp_t gfp_mask,
>> + int nid, nodemask_t *nodemask)
>
> One of the objections when Mike has proposed a similar thing last year
> was that the interface shouldn't be order bases
> http://lkml.kernel.org/r/20180423000943.GO17484@dhcp22.suse.cz
>
> Order based API makes sense for the buddy allocator but why should we
> restrict sizes like that for an allocator that is capable to allocate
> arbitrary page sized requests?
Fair enough, will change it. Anyways we calculate nr_pages from the order
argument at the very beginning.
WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
James Hogan <jhogan@kernel.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dave Hansen <dave.hansen@intel.com>,
Paul Mackerras <paulus@samba.org>,
sparclinux@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-s390@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>,
x86@kernel.org, Russell King - ARM Linux <linux@armlinux.org.uk>,
Matthew Wilcox <willy@infradead.org>,
Steven Price <Steven.Price@arm.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
David Rientjes <rientjes@google.com>,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Kees Cook <keescook@chromium.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
linuxppc-dev@lists.ozlabs.org, Mark Brown <broonie@kernel.org>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
Dan Williams <dan.j.williams@intel.com>,
Vlastimil Babka <vbabka@suse.cz>,
Oscar Salvador <osalvador@suse.de>,
Christophe Leroy <christophe.leroy@c-s.fr>,
Sri Krishna chowdary <schowdary@nvidia.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-mips@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
Paul Burton <paul.burton@mips.com>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
Vineet Gupta <vgupta@synopsys.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@techsingularity.net>,
"David S. Miller" <davem@davemloft.net>,
Mike Kravetz <mike.kravetz@oracle.com>
Subject: Re: [PATCH V6 1/2] mm/page_alloc: Make alloc_gigantic_page() available for general use
Date: Tue, 15 Oct 2019 16:37:27 +0530 [thread overview]
Message-ID: <2d4e7b28-67bf-baf3-b8a0-a5b3a58e3b31@arm.com> (raw)
In-Reply-To: <20191015104521.GY317@dhcp22.suse.cz>
On 10/15/2019 04:15 PM, Michal Hocko wrote:
> On Tue 15-10-19 14:51:41, Anshuman Khandual wrote:
> [...]
>> +/**
>> + * alloc_gigantic_page_order() -- tries to allocate given order of pages
>> + * @order: allocation order (greater than MAX_ORDER)
>> + * @gfp_mask: GFP mask to use during compaction
>> + * @nid: allocation node
>> + * @nodemask: allocation nodemask
>> + *
>> + * This routine is an wrapper around alloc_contig_range() which scans over
>> + * all zones on an applicable zonelist to find a contiguous pfn range which
>> + * can the be allocated with alloc_contig_range(). This routine is intended
>> + * to be used for allocations greater than MAX_ORDER.
>> + *
>> + * Return: page on success or NULL on failure. On success a memory block
>> + * of 'order' starting with 'page' has been allocated successfully. Memory
>> + * allocated here needs to be freed with free_contig_range().
>> + */
>> +struct page *alloc_gigantic_page_order(unsigned int order, gfp_t gfp_mask,
>> + int nid, nodemask_t *nodemask)
>
> One of the objections when Mike has proposed a similar thing last year
> was that the interface shouldn't be order bases
> http://lkml.kernel.org/r/20180423000943.GO17484@dhcp22.suse.cz
>
> Order based API makes sense for the buddy allocator but why should we
> restrict sizes like that for an allocator that is capable to allocate
> arbitrary page sized requests?
Fair enough, will change it. Anyways we calculate nr_pages from the order
argument at the very beginning.
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
James Hogan <jhogan@kernel.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dave Hansen <dave.hansen@intel.com>,
Paul Mackerras <paulus@samba.org>,
sparclinux@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-s390@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>,
x86@kernel.org, Russell King - ARM Linux <linux@armlinux.org.uk>,
Matthew Wilcox <willy@infradead.org>,
Steven Price <Steven.Price@arm.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
David Rientjes <rientjes@google.com>,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Kees Cook <keescook@chromium.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
linuxppc-dev@lists.ozlabs.org, Mark Brown <broonie@kernel.org>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
Dan Williams <dan.j.williams@intel.com>,
Vlastimil Babka <vbabka@suse.cz>,
Oscar Salvador <osalvador@suse.de>,
Christophe Leroy <christophe.leroy@c-s.fr>,
Sri Krishna chowdary <schowdary@nvidia.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-mips@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
Paul Burton <paul.burton@mips.com>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
Vineet Gupta <vgupta@synopsys.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@techsingularity.net>,
"David S. Miller" <davem@davemloft.net>,
Mike Kravetz <mike.kravetz@oracle.com>
Subject: Re: [PATCH V6 1/2] mm/page_alloc: Make alloc_gigantic_page() available for general use
Date: Tue, 15 Oct 2019 16:37:27 +0530 [thread overview]
Message-ID: <2d4e7b28-67bf-baf3-b8a0-a5b3a58e3b31@arm.com> (raw)
In-Reply-To: <20191015104521.GY317@dhcp22.suse.cz>
On 10/15/2019 04:15 PM, Michal Hocko wrote:
> On Tue 15-10-19 14:51:41, Anshuman Khandual wrote:
> [...]
>> +/**
>> + * alloc_gigantic_page_order() -- tries to allocate given order of pages
>> + * @order: allocation order (greater than MAX_ORDER)
>> + * @gfp_mask: GFP mask to use during compaction
>> + * @nid: allocation node
>> + * @nodemask: allocation nodemask
>> + *
>> + * This routine is an wrapper around alloc_contig_range() which scans over
>> + * all zones on an applicable zonelist to find a contiguous pfn range which
>> + * can the be allocated with alloc_contig_range(). This routine is intended
>> + * to be used for allocations greater than MAX_ORDER.
>> + *
>> + * Return: page on success or NULL on failure. On success a memory block
>> + * of 'order' starting with 'page' has been allocated successfully. Memory
>> + * allocated here needs to be freed with free_contig_range().
>> + */
>> +struct page *alloc_gigantic_page_order(unsigned int order, gfp_t gfp_mask,
>> + int nid, nodemask_t *nodemask)
>
> One of the objections when Mike has proposed a similar thing last year
> was that the interface shouldn't be order bases
> http://lkml.kernel.org/r/20180423000943.GO17484@dhcp22.suse.cz
>
> Order based API makes sense for the buddy allocator but why should we
> restrict sizes like that for an allocator that is capable to allocate
> arbitrary page sized requests?
Fair enough, will change it. Anyways we calculate nr_pages from the order
argument at the very beginning.
_______________________________________________
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:[~2019-10-15 11:07 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-15 9:21 [PATCH V6 0/2] mm/debug: Add tests validating architecture page table helpers Anshuman Khandual
2019-10-15 9:33 ` Anshuman Khandual
2019-10-15 9:21 ` Anshuman Khandual
2019-10-15 9:21 ` Anshuman Khandual
2019-10-15 9:21 ` [PATCH V6 1/2] mm/page_alloc: Make alloc_gigantic_page() available for general use Anshuman Khandual
2019-10-15 9:21 ` Anshuman Khandual
2019-10-15 9:21 ` Anshuman Khandual
2019-10-15 10:45 ` Michal Hocko
2019-10-15 10:45 ` Michal Hocko
2019-10-15 10:45 ` Michal Hocko
2019-10-15 10:45 ` Michal Hocko
2019-10-15 11:07 ` Anshuman Khandual [this message]
2019-10-15 11:07 ` Anshuman Khandual
2019-10-15 11:07 ` Anshuman Khandual
2019-10-15 11:07 ` Anshuman Khandual
2019-10-15 11:42 ` David Hildenbrand
2019-10-15 11:42 ` David Hildenbrand
2019-10-15 11:42 ` David Hildenbrand
2019-10-15 11:42 ` David Hildenbrand
2019-10-15 11:47 ` Michal Hocko
2019-10-15 11:47 ` Michal Hocko
2019-10-15 11:47 ` Michal Hocko
2019-10-15 11:47 ` Michal Hocko
2019-10-15 11:50 ` David Hildenbrand
2019-10-15 11:50 ` David Hildenbrand
2019-10-15 11:50 ` David Hildenbrand
2019-10-15 11:50 ` David Hildenbrand
2019-10-15 12:01 ` David Hildenbrand
2019-10-15 12:01 ` David Hildenbrand
2019-10-15 12:01 ` David Hildenbrand
2019-10-15 12:01 ` David Hildenbrand
2019-10-15 12:09 ` Michal Hocko
2019-10-15 12:09 ` Michal Hocko
2019-10-15 12:09 ` Michal Hocko
2019-10-15 12:09 ` Michal Hocko
2019-10-15 12:11 ` Michal Hocko
2019-10-15 12:11 ` Michal Hocko
2019-10-15 12:11 ` Michal Hocko
2019-10-15 12:11 ` Michal Hocko
2019-10-15 9:21 ` [PATCH V6 2/2] mm/debug: Add tests validating architecture page table helpers Anshuman Khandual
2019-10-15 9:33 ` Anshuman Khandual
2019-10-15 9:21 ` Anshuman Khandual
2019-10-15 9:21 ` Anshuman Khandual
2019-10-15 11:46 ` Michal Hocko
2019-10-15 11:46 ` Michal Hocko
2019-10-15 11:46 ` Michal Hocko
2019-10-15 11:46 ` Michal Hocko
2019-10-15 11:46 ` Michal Hocko
2019-10-15 12:27 ` Anshuman Khandual
2019-10-15 12:39 ` Anshuman Khandual
2019-10-15 12:27 ` Anshuman Khandual
2019-10-15 12:27 ` Anshuman Khandual
2019-10-15 12:27 ` Anshuman Khandual
2019-10-15 18:09 ` Qian Cai
2019-10-15 18:09 ` Qian Cai
2019-10-15 18:09 ` Qian Cai
2019-10-15 18:09 ` Qian Cai
2019-10-15 18:09 ` Qian Cai
2019-10-15 18:09 ` Qian Cai
2019-10-16 9:54 ` Anshuman Khandual
2019-10-16 9:54 ` Anshuman Khandual
2019-10-16 9:54 ` Anshuman Khandual
2019-10-16 9:54 ` Anshuman Khandual
2019-10-16 9:54 ` Anshuman Khandual
2019-10-15 14:41 ` [PATCH V6 0/2] " Qian Cai
2019-10-15 14:41 ` Qian Cai
2019-10-15 14:41 ` Qian Cai
2019-10-15 14:41 ` Qian Cai
2019-10-15 14:41 ` Qian Cai
2019-10-15 14:41 ` Qian Cai
2019-10-15 15:21 ` Anshuman Khandual
2019-10-15 15:33 ` Anshuman Khandual
2019-10-15 15:21 ` Anshuman Khandual
2019-10-15 15:21 ` Anshuman Khandual
2019-10-15 15:21 ` Anshuman Khandual
2019-10-15 18:42 ` Qian Cai
2019-10-15 18:42 ` Qian Cai
2019-10-15 18:42 ` Qian Cai
2019-10-15 18:42 ` Qian Cai
2019-10-15 18:42 ` Qian Cai
2019-10-15 18:42 ` Qian Cai
2019-10-16 8:59 ` Anshuman Khandual
2019-10-16 9:11 ` Anshuman Khandual
2019-10-16 8:59 ` Anshuman Khandual
2019-10-16 8:59 ` Anshuman Khandual
2019-10-16 8:59 ` Anshuman Khandual
2019-10-16 8:20 ` Michal Hocko
2019-10-16 8:20 ` Michal Hocko
2019-10-16 8:20 ` Michal Hocko
2019-10-16 8:20 ` Michal Hocko
2019-10-16 8:20 ` Michal Hocko
2019-10-16 8:20 ` Michal Hocko
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=2d4e7b28-67bf-baf3-b8a0-a5b3a58e3b31@arm.com \
--to=anshuman.khandual@arm.com \
--cc=Steven.Price@arm.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=broonie@kernel.org \
--cc=christophe.leroy@c-s.fr \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=davem@davemloft.net \
--cc=gerald.schaefer@de.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=heiko.carstens@de.ibm.com \
--cc=jgg@ziepe.ca \
--cc=jhogan@kernel.org \
--cc=keescook@chromium.org \
--cc=kirill@shutemov.name \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.rutland@arm.com \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=mike.kravetz@oracle.com \
--cc=mpe@ellerman.id.au \
--cc=osalvador@suse.de \
--cc=paul.burton@mips.com \
--cc=paulus@samba.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=ralf@linux-mips.org \
--cc=rientjes@google.com \
--cc=rppt@linux.vnet.ibm.com \
--cc=schowdary@nvidia.com \
--cc=schwidefsky@de.ibm.com \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=vgupta@synopsys.com \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.com \
/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.