From: Mel Gorman <mel@csn.ul.ie>
To: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: linux-kernel@vger.kernel.org,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Christoph Lameter <cl@linux.com>,
Chris Metcalf <cmetcalf@tilera.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Frederic Weisbecker <fweisbec@gmail.com>,
Russell King <linux@arm.linux.org.uk>,
linux-mm@kvack.org, Pekka Enberg <penberg@kernel.org>,
Matt Mackall <mpm@selenic.com>,
Sasha Levin <levinsasha928@gmail.com>,
Rik van Riel <riel@redhat.com>, Andi Kleen <andi@firstfloor.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, Avi Kivity <avi@redhat.com>,
Michal Nazarewicz <mina86@mina86.com>,
Milton Miller <miltonm@bga.com>
Subject: Re: [v7 7/8] mm: only IPI CPUs to drain local pages if they exist
Date: Mon, 30 Jan 2012 14:59:00 +0000 [thread overview]
Message-ID: <20120130145900.GR25268@csn.ul.ie> (raw)
In-Reply-To: <1327572121-13673-8-git-send-email-gilad@benyossef.com>
On Thu, Jan 26, 2012 at 12:02:00PM +0200, Gilad Ben-Yossef wrote:
> Calculate a cpumask of CPUs with per-cpu pages in any zone
> and only send an IPI requesting CPUs to drain these pages
> to the buddy allocator if they actually have pages when
> asked to flush.
>
> This patch saves 85%+ of IPIs asking to drain per-cpu
> pages in case of severe memory preassure that leads
> to OOM since in these cases multiple, possibly concurrent,
> allocation requests end up in the direct reclaim code
> path so when the per-cpu pages end up reclaimed on first
> allocation failure for most of the proceeding allocation
> attempts until the memory pressure is off (possibly via
> the OOM killer) there are no per-cpu pages on most CPUs
> (and there can easily be hundreds of them).
>
> This also has the side effect of shortening the average
> latency of direct reclaim by 1 or more order of magnitude
> since waiting for all the CPUs to ACK the IPI takes a
> long time.
>
> Tested by running "hackbench 400" on a 8 CPU x86 VM and
> observing the difference between the number of direct
> reclaim attempts that end up in drain_all_pages() and
> those were more then 1/2 of the online CPU had any per-cpu
> page in them, using the vmstat counters introduced
> in the next patch in the series and using proc/interrupts.
>
> In the test sceanrio, this was seen to save around 3600 global
> IPIs after trigerring an OOM on a concurrent workload:
>
> $ cat /proc/vmstat | tail -n 2
> pcp_global_drain 0
> pcp_global_ipi_saved 0
>
> $ cat /proc/interrupts | grep CAL
> CAL: 1 2 1 2
> 2 2 2 2 Function call interrupts
>
> $ hackbench 400
> [OOM messages snipped]
>
> $ cat /proc/vmstat | tail -n 2
> pcp_global_drain 3647
> pcp_global_ipi_saved 3642
>
> $ cat /proc/interrupts | grep CAL
> CAL: 6 13 6 3
> 3 3 1 2 7 Function call interrupts
>
> Please note that if the global drain is removed from the
> direct reclaim path as a patch from Mel Gorman currently
> suggests this should be replaced with an on_each_cpu_cond
> invocation.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
> CC: Mel Gorman <mel@csn.ul.ie>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: Christoph Lameter <cl@linux.com>
> CC: Chris Metcalf <cmetcalf@tilera.com>
> CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
> CC: Frederic Weisbecker <fweisbec@gmail.com>
> CC: Russell King <linux@arm.linux.org.uk>
> CC: linux-mm@kvack.org
> CC: Pekka Enberg <penberg@kernel.org>
> CC: Matt Mackall <mpm@selenic.com>
> CC: Sasha Levin <levinsasha928@gmail.com>
> CC: Rik van Riel <riel@redhat.com>
> CC: Andi Kleen <andi@firstfloor.org>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Alexander Viro <viro@zeniv.linux.org.uk>
> CC: linux-fsdevel@vger.kernel.org
> CC: Avi Kivity <avi@redhat.com>
> CC: Michal Nazarewicz <mina86@mina86.com>
> CC: Milton Miller <miltonm@bga.com>
> ---
> mm/page_alloc.c | 31 ++++++++++++++++++++++++++++++-
> 1 files changed, 30 insertions(+), 1 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d2186ec..4135983 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1165,7 +1165,36 @@ void drain_local_pages(void *arg)
> */
> void drain_all_pages(void)
> {
> - on_each_cpu(drain_local_pages, NULL, 1);
> + int cpu;
> + struct per_cpu_pageset *pcp;
> + struct zone *zone;
> +
> + /* Allocate in the BSS so we wont require allocation in
> + * direct reclaim path for CONFIG_CPUMASK_OFFSTACK=y
> + */
> + static cpumask_t cpus_with_pcps;
> +
> + /*
> + * We don't care about racing with CPU hotplug event
> + * as offline notification will cause the notified
> + * cpu to drain that CPU pcps and on_each_cpu_mask
> + * disables preemption as part of its processing
> + */
> + for_each_online_cpu(cpu) {
> + bool has_pcps = false;
> + for_each_populated_zone(zone) {
> + pcp = per_cpu_ptr(zone->pageset, cpu);
> + if (pcp->pcp.count) {
> + has_pcps = true;
> + break;
> + }
> + }
> + if (has_pcps)
> + cpumask_set_cpu(cpu, &cpus_with_pcps);
> + else
> + cpumask_clear_cpu(cpu, &cpus_with_pcps);
> + }
Lets take two CPUs running this code at the same time. CPU 1 has per-cpu
pages in all zones. CPU 2 has no per-cpu pages in any zone. If both run
at the same time, CPU 2 can be clearing the mask for CPU 1 before it has
had a chance to send the IPI. This means we'll miss sending IPIs to CPUs
that we intended to. As I was willing to send no IPI at all;
Acked-by: Mel Gorman <mel@csn.ul.ie>
But if this gets another revision, add a comment saying that two CPUs
can interfere with each other running at the same time but we don't
care.
> + on_each_cpu_mask(&cpus_with_pcps, drain_local_pages, NULL, 1);
> }
>
> #ifdef CONFIG_HIBERNATION
> --
> 1.7.0.4
>
--
Mel Gorman
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mel@csn.ul.ie>
To: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: linux-kernel@vger.kernel.org,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Christoph Lameter <cl@linux.com>,
Chris Metcalf <cmetcalf@tilera.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Frederic Weisbecker <fweisbec@gmail.com>,
Russell King <linux@arm.linux.org.uk>,
linux-mm@kvack.org, Pekka Enberg <penberg@kernel.org>,
Matt Mackall <mpm@selenic.com>,
Sasha Levin <levinsasha928@gmail.com>,
Rik van Riel <riel@redhat.com>, Andi Kleen <andi@firstfloor.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, Avi Kivity <avi@redhat.com>,
Michal Nazarewicz <mina86@mina86.com>,
Milton Miller <miltonm@bga.com>
Subject: Re: [v7 7/8] mm: only IPI CPUs to drain local pages if they exist
Date: Mon, 30 Jan 2012 14:59:00 +0000 [thread overview]
Message-ID: <20120130145900.GR25268@csn.ul.ie> (raw)
In-Reply-To: <1327572121-13673-8-git-send-email-gilad@benyossef.com>
On Thu, Jan 26, 2012 at 12:02:00PM +0200, Gilad Ben-Yossef wrote:
> Calculate a cpumask of CPUs with per-cpu pages in any zone
> and only send an IPI requesting CPUs to drain these pages
> to the buddy allocator if they actually have pages when
> asked to flush.
>
> This patch saves 85%+ of IPIs asking to drain per-cpu
> pages in case of severe memory preassure that leads
> to OOM since in these cases multiple, possibly concurrent,
> allocation requests end up in the direct reclaim code
> path so when the per-cpu pages end up reclaimed on first
> allocation failure for most of the proceeding allocation
> attempts until the memory pressure is off (possibly via
> the OOM killer) there are no per-cpu pages on most CPUs
> (and there can easily be hundreds of them).
>
> This also has the side effect of shortening the average
> latency of direct reclaim by 1 or more order of magnitude
> since waiting for all the CPUs to ACK the IPI takes a
> long time.
>
> Tested by running "hackbench 400" on a 8 CPU x86 VM and
> observing the difference between the number of direct
> reclaim attempts that end up in drain_all_pages() and
> those were more then 1/2 of the online CPU had any per-cpu
> page in them, using the vmstat counters introduced
> in the next patch in the series and using proc/interrupts.
>
> In the test sceanrio, this was seen to save around 3600 global
> IPIs after trigerring an OOM on a concurrent workload:
>
> $ cat /proc/vmstat | tail -n 2
> pcp_global_drain 0
> pcp_global_ipi_saved 0
>
> $ cat /proc/interrupts | grep CAL
> CAL: 1 2 1 2
> 2 2 2 2 Function call interrupts
>
> $ hackbench 400
> [OOM messages snipped]
>
> $ cat /proc/vmstat | tail -n 2
> pcp_global_drain 3647
> pcp_global_ipi_saved 3642
>
> $ cat /proc/interrupts | grep CAL
> CAL: 6 13 6 3
> 3 3 1 2 7 Function call interrupts
>
> Please note that if the global drain is removed from the
> direct reclaim path as a patch from Mel Gorman currently
> suggests this should be replaced with an on_each_cpu_cond
> invocation.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
> CC: Mel Gorman <mel@csn.ul.ie>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: Christoph Lameter <cl@linux.com>
> CC: Chris Metcalf <cmetcalf@tilera.com>
> CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
> CC: Frederic Weisbecker <fweisbec@gmail.com>
> CC: Russell King <linux@arm.linux.org.uk>
> CC: linux-mm@kvack.org
> CC: Pekka Enberg <penberg@kernel.org>
> CC: Matt Mackall <mpm@selenic.com>
> CC: Sasha Levin <levinsasha928@gmail.com>
> CC: Rik van Riel <riel@redhat.com>
> CC: Andi Kleen <andi@firstfloor.org>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Alexander Viro <viro@zeniv.linux.org.uk>
> CC: linux-fsdevel@vger.kernel.org
> CC: Avi Kivity <avi@redhat.com>
> CC: Michal Nazarewicz <mina86@mina86.com>
> CC: Milton Miller <miltonm@bga.com>
> ---
> mm/page_alloc.c | 31 ++++++++++++++++++++++++++++++-
> 1 files changed, 30 insertions(+), 1 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d2186ec..4135983 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1165,7 +1165,36 @@ void drain_local_pages(void *arg)
> */
> void drain_all_pages(void)
> {
> - on_each_cpu(drain_local_pages, NULL, 1);
> + int cpu;
> + struct per_cpu_pageset *pcp;
> + struct zone *zone;
> +
> + /* Allocate in the BSS so we wont require allocation in
> + * direct reclaim path for CONFIG_CPUMASK_OFFSTACK=y
> + */
> + static cpumask_t cpus_with_pcps;
> +
> + /*
> + * We don't care about racing with CPU hotplug event
> + * as offline notification will cause the notified
> + * cpu to drain that CPU pcps and on_each_cpu_mask
> + * disables preemption as part of its processing
> + */
> + for_each_online_cpu(cpu) {
> + bool has_pcps = false;
> + for_each_populated_zone(zone) {
> + pcp = per_cpu_ptr(zone->pageset, cpu);
> + if (pcp->pcp.count) {
> + has_pcps = true;
> + break;
> + }
> + }
> + if (has_pcps)
> + cpumask_set_cpu(cpu, &cpus_with_pcps);
> + else
> + cpumask_clear_cpu(cpu, &cpus_with_pcps);
> + }
Lets take two CPUs running this code at the same time. CPU 1 has per-cpu
pages in all zones. CPU 2 has no per-cpu pages in any zone. If both run
at the same time, CPU 2 can be clearing the mask for CPU 1 before it has
had a chance to send the IPI. This means we'll miss sending IPIs to CPUs
that we intended to. As I was willing to send no IPI at all;
Acked-by: Mel Gorman <mel@csn.ul.ie>
But if this gets another revision, add a comment saying that two CPUs
can interfere with each other running at the same time but we don't
care.
> + on_each_cpu_mask(&cpus_with_pcps, drain_local_pages, NULL, 1);
> }
>
> #ifdef CONFIG_HIBERNATION
> --
> 1.7.0.4
>
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2012-01-30 14:59 UTC|newest]
Thread overview: 154+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-26 10:01 [v7 0/8] Reduce cross CPU IPI interference Gilad Ben-Yossef
2012-01-26 10:01 ` Gilad Ben-Yossef
2012-01-26 10:01 ` [v7 1/8] smp: introduce a generic on_each_cpu_mask function Gilad Ben-Yossef
2012-01-26 10:01 ` Gilad Ben-Yossef
2012-01-29 12:24 ` Gilad Ben-Yossef
2012-01-29 12:24 ` Gilad Ben-Yossef
2012-01-30 21:52 ` Andrew Morton
2012-01-30 21:52 ` Andrew Morton
2012-01-31 6:33 ` Gilad Ben-Yossef
2012-01-31 6:33 ` Gilad Ben-Yossef
2012-01-26 10:01 ` [v7 2/8] arm: move arm over to generic on_each_cpu_mask Gilad Ben-Yossef
2012-01-26 10:01 ` Gilad Ben-Yossef
2012-01-26 10:01 ` [v7 3/8] tile: move tile to use " Gilad Ben-Yossef
2012-01-26 10:01 ` Gilad Ben-Yossef
2012-01-26 10:01 ` [v7 4/8] smp: add func to IPI cpus based on parameter func Gilad Ben-Yossef
2012-01-26 10:01 ` Gilad Ben-Yossef
2012-01-27 23:57 ` Andrew Morton
2012-01-27 23:57 ` Andrew Morton
2012-01-29 12:04 ` Gilad Ben-Yossef
2012-01-29 12:04 ` Gilad Ben-Yossef
2012-01-26 10:01 ` [v7 5/8] slub: only IPI CPUs that have per cpu obj to flush Gilad Ben-Yossef
2012-01-26 10:01 ` Gilad Ben-Yossef
2012-01-26 15:09 ` Christoph Lameter
2012-01-26 15:09 ` Christoph Lameter
2012-01-26 10:01 ` [v7 6/8] fs: only send IPI to invalidate LRU BH when needed Gilad Ben-Yossef
2012-01-26 10:01 ` Gilad Ben-Yossef
2012-01-26 10:02 ` [v7 7/8] mm: only IPI CPUs to drain local pages if they exist Gilad Ben-Yossef
2012-01-26 10:02 ` Gilad Ben-Yossef
2012-01-26 15:13 ` Christoph Lameter
2012-01-26 15:13 ` Christoph Lameter
2012-01-28 0:12 ` Andrew Morton
2012-01-28 0:12 ` Andrew Morton
2012-01-29 12:18 ` Gilad Ben-Yossef
2012-01-29 12:18 ` Gilad Ben-Yossef
2012-01-30 21:49 ` Andrew Morton
2012-01-30 21:49 ` Andrew Morton
2012-01-31 6:32 ` Gilad Ben-Yossef
2012-01-31 6:32 ` Gilad Ben-Yossef
2012-01-30 14:59 ` Mel Gorman [this message]
2012-01-30 14:59 ` Mel Gorman
2012-01-30 15:14 ` Gilad Ben-Yossef
2012-01-30 15:14 ` Gilad Ben-Yossef
2012-01-30 15:44 ` Mel Gorman
2012-01-30 15:44 ` Mel Gorman
2012-01-30 15:44 ` Mel Gorman
2012-01-26 10:02 ` [v7 8/8] mm: add vmstat counters for tracking PCP drains Gilad Ben-Yossef
2012-01-26 10:02 ` Gilad Ben-Yossef
2012-01-26 15:19 ` [v7 0/8] Reduce cross CPU IPI interference Peter Zijlstra
2012-01-26 15:19 ` Peter Zijlstra
2012-01-29 8:25 ` Gilad Ben-Yossef
2012-01-29 8:25 ` Gilad Ben-Yossef
2012-02-01 17:04 ` Frederic Weisbecker
2012-02-01 17:04 ` Frederic Weisbecker
2012-02-02 8:46 ` Gilad Ben-Yossef
2012-02-02 8:46 ` Gilad Ben-Yossef
2012-02-02 15:41 ` Chris Metcalf
2012-02-02 15:41 ` Chris Metcalf
2012-02-05 11:46 ` Gilad Ben-Yossef
2012-02-05 11:46 ` Gilad Ben-Yossef
2012-02-10 18:39 ` Peter Zijlstra
2012-02-10 18:39 ` Peter Zijlstra
2012-02-10 20:13 ` Gilad Ben-Yossef
2012-02-10 20:13 ` Gilad Ben-Yossef
2012-02-10 20:29 ` Peter Zijlstra
2012-02-10 20:29 ` Peter Zijlstra
2012-02-10 20:39 ` Gilad Ben-Yossef
2012-02-10 20:39 ` Gilad Ben-Yossef
2012-02-10 18:33 ` Peter Zijlstra
2012-02-10 18:33 ` Peter Zijlstra
2012-02-10 20:33 ` Gilad Ben-Yossef
2012-02-10 20:33 ` Gilad Ben-Yossef
2012-02-15 21:50 ` Chris Metcalf
2012-02-15 21:50 ` Chris Metcalf
2012-02-15 22:15 ` Christoph Lameter
2012-02-15 22:15 ` Christoph Lameter
2012-02-15 23:44 ` Chris Metcalf
2012-02-15 23:44 ` Chris Metcalf
2012-02-21 1:34 ` Frederic Weisbecker
2012-02-21 1:34 ` Frederic Weisbecker
2012-03-01 18:27 ` Chris Metcalf
2012-03-01 18:27 ` Chris Metcalf
2012-02-10 18:38 ` Peter Zijlstra
2012-02-10 18:38 ` Peter Zijlstra
2012-02-10 20:24 ` Gilad Ben-Yossef
2012-02-10 20:24 ` Gilad Ben-Yossef
2012-02-15 15:11 ` Peter Zijlstra
2012-02-15 15:11 ` Peter Zijlstra
2012-02-15 15:19 ` Gilad Ben-Yossef
2012-02-15 15:19 ` Gilad Ben-Yossef
2012-02-15 21:51 ` Chris Metcalf
2012-02-15 21:51 ` Chris Metcalf
2012-02-02 16:24 ` Frederic Weisbecker
2012-02-02 16:24 ` Frederic Weisbecker
2012-02-02 16:29 ` Christoph Lameter
2012-02-09 15:52 ` Frederic Weisbecker
2012-02-09 15:52 ` Frederic Weisbecker
2012-02-09 15:59 ` Chris Metcalf
2012-02-09 15:59 ` Chris Metcalf
2012-02-09 18:11 ` Frederic Weisbecker
2012-02-09 18:11 ` Frederic Weisbecker
2012-02-09 16:26 ` Christoph Lameter
2012-02-09 16:26 ` Christoph Lameter
2012-02-09 18:32 ` Frederic Weisbecker
2012-02-09 18:32 ` Frederic Weisbecker
2012-02-01 17:35 ` Peter Zijlstra
2012-02-01 17:35 ` Peter Zijlstra
2012-02-01 17:57 ` Peter Zijlstra
2012-02-01 17:57 ` Peter Zijlstra
2012-02-02 9:42 ` Gilad Ben-Yossef
2012-02-02 9:42 ` Gilad Ben-Yossef
2012-02-01 18:40 ` Paul E. McKenney
2012-02-01 18:40 ` Paul E. McKenney
2012-02-01 20:06 ` Christoph Lameter
2012-02-01 20:06 ` Christoph Lameter
2012-02-01 20:13 ` Paul E. McKenney
2012-02-01 20:13 ` Paul E. McKenney
2012-02-02 9:34 ` Avi Kivity
2012-02-02 9:34 ` Avi Kivity
2012-02-02 15:34 ` Paul E. McKenney
2012-02-02 15:34 ` Paul E. McKenney
2012-02-02 16:14 ` Avi Kivity
2012-02-02 16:14 ` Avi Kivity
2012-02-02 17:01 ` Paul E. McKenney
2012-02-02 17:01 ` Paul E. McKenney
2012-02-02 17:23 ` Avi Kivity
2012-02-02 17:23 ` Avi Kivity
2012-02-02 17:51 ` Paul E. McKenney
2012-02-02 17:51 ` Paul E. McKenney
2012-02-05 12:16 ` Avi Kivity
2012-02-05 12:16 ` Avi Kivity
2012-02-05 16:59 ` Paul E. McKenney
2012-02-05 16:59 ` Paul E. McKenney
2012-02-09 15:22 ` Frederic Weisbecker
2012-02-09 15:22 ` Frederic Weisbecker
2012-02-09 16:05 ` Avi Kivity
2012-02-09 16:05 ` Avi Kivity
2012-02-09 18:22 ` Frederic Weisbecker
2012-02-09 18:22 ` Frederic Weisbecker
2012-02-09 23:41 ` Paul E. McKenney
2012-02-09 23:41 ` Paul E. McKenney
2012-02-10 1:39 ` Frederic Weisbecker
2012-02-10 1:39 ` Frederic Weisbecker
2012-02-14 13:18 ` Avi Kivity
2012-02-14 13:18 ` Avi Kivity
2012-02-21 0:02 ` Frederic Weisbecker
2012-02-21 0:02 ` Frederic Weisbecker
2012-02-02 17:25 ` Christoph Lameter
2012-02-02 17:25 ` Christoph Lameter
2012-02-05 12:06 ` Gilad Ben-Yossef
2012-02-05 12:06 ` Gilad Ben-Yossef
2012-02-06 18:19 ` Christoph Lameter
2012-02-06 18:19 ` Christoph Lameter
2012-02-09 15:37 ` Frederic Weisbecker
2012-02-09 15:37 ` Frederic Weisbecker
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=20120130145900.GR25268@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=avi@redhat.com \
--cc=cl@linux.com \
--cc=cmetcalf@tilera.com \
--cc=fweisbec@gmail.com \
--cc=gilad@benyossef.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=levinsasha928@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@arm.linux.org.uk \
--cc=miltonm@bga.com \
--cc=mina86@mina86.com \
--cc=mpm@selenic.com \
--cc=penberg@kernel.org \
--cc=riel@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/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.