All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linuxppc-dev@ozlabs.org, Ingo Molnar <mingo@elte.hu>,
	Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
	Balbir Singh <balbir@linux.vnet.ibm.com>
Subject: Re: [BUG] Linux 2.6.25-rc2 - Regression from 2.6.24-rc1-git1 softlockup while bootup on powerpc
Date: Tue, 19 Feb 2008 09:36:34 +0100	[thread overview]
Message-ID: <20080219083633.GN23197@kernel.dk> (raw)
In-Reply-To: <20080219170432.9c04376f.kamezawa.hiroyu@jp.fujitsu.com>

On Tue, Feb 19 2008, KAMEZAWA Hiroyuki wrote:
> On Sun, 17 Feb 2008 20:29:13 +0100
> Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > It's odd stuff. Could you perhaps try and add some printks to
> > block/cfq-iosched.c:call_for_each_cic(), like dumping the 'nr' return
> > from radix_tree_gang_lookup() and the pointer value of cics[i] in the
> > for() loop after the lookup?
> > 
> I met the same issue on ia64/NUMA box.
> seems cisc[]->key is NULL and index for radix_tree_gang_lookup() was
> always '1'.

Why does it keep repeating then? If ->key is NULL, the next lookup index
should be 1UL.

But I think the radix 'scan over entire tree' is a bit fragile. This
patch adds a parallel hlist for ease of properly browsing the members,
does that work for you? It compiles, but I haven't booted it here yet...

> Attached patch works well for me, but I don't know much about cfq.
> please confirm. 

It doesn't make a lot of sense, I'm afraid.

 block/blk-ioc.c           |   35 +++++++++++++++--------------------
 block/cfq-iosched.c       |   37 +++++++++++--------------------------
 include/linux/iocontext.h |    2 ++
 3 files changed, 28 insertions(+), 46 deletions(-)

diff --git a/block/blk-ioc.c b/block/blk-ioc.c
index 80245dc..73c7002 100644
--- a/block/blk-ioc.c
+++ b/block/blk-ioc.c
@@ -17,17 +17,13 @@ static struct kmem_cache *iocontext_cachep;
 
 static void cfq_dtor(struct io_context *ioc)
 {
-	struct cfq_io_context *cic[1];
-	int r;
+	if (!hlist_empty(&ioc->cic_list)) {
+		struct cfq_io_context *cic;
 
-	/*
-	 * We don't have a specific key to lookup with, so use the gang
-	 * lookup to just retrieve the first item stored. The cfq exit
-	 * function will iterate the full tree, so any member will do.
-	 */
-	r = radix_tree_gang_lookup(&ioc->radix_root, (void **) cic, 0, 1);
-	if (r > 0)
-		cic[0]->dtor(ioc);
+		cic = list_entry(ioc->cic_list.first, struct cfq_io_context,
+								cic_list);
+		cic->dtor(ioc);
+	}
 }
 
 /*
@@ -57,18 +53,16 @@ EXPORT_SYMBOL(put_io_context);
 
 static void cfq_exit(struct io_context *ioc)
 {
-	struct cfq_io_context *cic[1];
-	int r;
-
 	rcu_read_lock();
-	/*
-	 * See comment for cfq_dtor()
-	 */
-	r = radix_tree_gang_lookup(&ioc->radix_root, (void **) cic, 0, 1);
-	rcu_read_unlock();
 
-	if (r > 0)
-		cic[0]->exit(ioc);
+	if (!hlist_empty(&ioc->cic_list)) {
+		struct cfq_io_context *cic;
+
+		cic = list_entry(ioc->cic_list.first, struct cfq_io_context,
+								cic_list);
+		cic->exit(ioc);
+	}
+	rcu_read_unlock();
 }
 
 /* Called by the exitting task */
@@ -105,6 +99,7 @@ struct io_context *alloc_io_context(gfp_t gfp_flags, int node)
 		ret->nr_batch_requests = 0; /* because this is 0 */
 		ret->aic = NULL;
 		INIT_RADIX_TREE(&ret->radix_root, GFP_ATOMIC | __GFP_HIGH);
+		INIT_HLIST_HEAD(&ret->cic_list);
 		ret->ioc_data = NULL;
 	}
 
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index ca198e6..62eda3f 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -1145,38 +1145,19 @@ static void cfq_put_queue(struct cfq_queue *cfqq)
 /*
  * Call func for each cic attached to this ioc. Returns number of cic's seen.
  */
-#define CIC_GANG_NR	16
 static unsigned int
 call_for_each_cic(struct io_context *ioc,
 		  void (*func)(struct io_context *, struct cfq_io_context *))
 {
-	struct cfq_io_context *cics[CIC_GANG_NR];
-	unsigned long index = 0;
-	unsigned int called = 0;
-	int nr;
+	struct cfq_io_context *cic;
+	struct hlist_node *n;
+	int called = 0;
 
 	rcu_read_lock();
-
-	do {
-		int i;
-
-		/*
-		 * Perhaps there's a better way - this just gang lookups from
-		 * 0 to the end, restarting after each CIC_GANG_NR from the
-		 * last key + 1.
-		 */
-		nr = radix_tree_gang_lookup(&ioc->radix_root, (void **) cics,
-						index, CIC_GANG_NR);
-		if (!nr)
-			break;
-
-		called += nr;
-		index = 1 + (unsigned long) cics[nr - 1]->key;
-
-		for (i = 0; i < nr; i++)
-			func(ioc, cics[i]);
-	} while (nr == CIC_GANG_NR);
-
+	hlist_for_each_entry_rcu(cic, n, &ioc->cic_list, cic_list) {
+		func(ioc, cic);
+		called++;
+	}
 	rcu_read_unlock();
 
 	return called;
@@ -1190,6 +1171,7 @@ static void cic_free_func(struct io_context *ioc, struct cfq_io_context *cic)
 
 	spin_lock_irqsave(&ioc->lock, flags);
 	radix_tree_delete(&ioc->radix_root, cic->dead_key);
+	hlist_del_rcu(&cic->cic_list);
 	spin_unlock_irqrestore(&ioc->lock, flags);
 
 	kmem_cache_free(cfq_ioc_pool, cic);
@@ -1280,6 +1262,7 @@ cfq_alloc_io_context(struct cfq_data *cfqd, gfp_t gfp_mask)
 	if (cic) {
 		cic->last_end_request = jiffies;
 		INIT_LIST_HEAD(&cic->queue_list);
+		INIT_HLIST_NODE(&cic->cic_list);
 		cic->dtor = cfq_free_io_context;
 		cic->exit = cfq_exit_io_context;
 		elv_ioc_count_inc(ioc_count);
@@ -1501,6 +1484,7 @@ cfq_drop_dead_cic(struct cfq_data *cfqd, struct io_context *ioc,
 		rcu_assign_pointer(ioc->ioc_data, NULL);
 
 	radix_tree_delete(&ioc->radix_root, (unsigned long) cfqd);
+	hlist_del_rcu(&cic->cic_list);
 	spin_unlock_irqrestore(&ioc->lock, flags);
 
 	cfq_cic_free(cic);
@@ -1561,6 +1545,7 @@ static int cfq_cic_link(struct cfq_data *cfqd, struct io_context *ioc,
 		spin_lock_irqsave(&ioc->lock, flags);
 		ret = radix_tree_insert(&ioc->radix_root,
 						(unsigned long) cfqd, cic);
+		hlist_add_head_rcu(&cic->cic_list, &ioc->cic_list);
 		spin_unlock_irqrestore(&ioc->lock, flags);
 
 		radix_tree_preload_end();
diff --git a/include/linux/iocontext.h b/include/linux/iocontext.h
index 593b222..1b4ccf2 100644
--- a/include/linux/iocontext.h
+++ b/include/linux/iocontext.h
@@ -50,6 +50,7 @@ struct cfq_io_context {
 	sector_t seek_mean;
 
 	struct list_head queue_list;
+	struct hlist_node cic_list;
 
 	void (*dtor)(struct io_context *); /* destructor */
 	void (*exit)(struct io_context *); /* called on task exit */
@@ -77,6 +78,7 @@ struct io_context {
 
 	struct as_io_context *aic;
 	struct radix_tree_root radix_root;
+	struct hlist_head cic_list;
 	void *ioc_data;
 };
 

-- 
Jens Axboe

WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <jens.axboe@oracle.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linuxppc-dev@ozlabs.org, Ingo Molnar <mingo@elte.hu>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Dhaval Giani <dhaval@linux.vnet.ibm.com>,
	Andy Whitcroft <apw@shadowen.org>,
	Balbir Singh <balbir@linux.vnet.ibm.com>
Subject: Re: [BUG] Linux 2.6.25-rc2 - Regression from 2.6.24-rc1-git1  softlockup  while bootup on powerpc
Date: Tue, 19 Feb 2008 09:36:34 +0100	[thread overview]
Message-ID: <20080219083633.GN23197@kernel.dk> (raw)
In-Reply-To: <20080219170432.9c04376f.kamezawa.hiroyu@jp.fujitsu.com>

On Tue, Feb 19 2008, KAMEZAWA Hiroyuki wrote:
> On Sun, 17 Feb 2008 20:29:13 +0100
> Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > It's odd stuff. Could you perhaps try and add some printks to
> > block/cfq-iosched.c:call_for_each_cic(), like dumping the 'nr' return
> > from radix_tree_gang_lookup() and the pointer value of cics[i] in the
> > for() loop after the lookup?
> > 
> I met the same issue on ia64/NUMA box.
> seems cisc[]->key is NULL and index for radix_tree_gang_lookup() was
> always '1'.

Why does it keep repeating then? If ->key is NULL, the next lookup index
should be 1UL.

But I think the radix 'scan over entire tree' is a bit fragile. This
patch adds a parallel hlist for ease of properly browsing the members,
does that work for you? It compiles, but I haven't booted it here yet...

> Attached patch works well for me, but I don't know much about cfq.
> please confirm. 

It doesn't make a lot of sense, I'm afraid.

 block/blk-ioc.c           |   35 +++++++++++++++--------------------
 block/cfq-iosched.c       |   37 +++++++++++--------------------------
 include/linux/iocontext.h |    2 ++
 3 files changed, 28 insertions(+), 46 deletions(-)

diff --git a/block/blk-ioc.c b/block/blk-ioc.c
index 80245dc..73c7002 100644
--- a/block/blk-ioc.c
+++ b/block/blk-ioc.c
@@ -17,17 +17,13 @@ static struct kmem_cache *iocontext_cachep;
 
 static void cfq_dtor(struct io_context *ioc)
 {
-	struct cfq_io_context *cic[1];
-	int r;
+	if (!hlist_empty(&ioc->cic_list)) {
+		struct cfq_io_context *cic;
 
-	/*
-	 * We don't have a specific key to lookup with, so use the gang
-	 * lookup to just retrieve the first item stored. The cfq exit
-	 * function will iterate the full tree, so any member will do.
-	 */
-	r = radix_tree_gang_lookup(&ioc->radix_root, (void **) cic, 0, 1);
-	if (r > 0)
-		cic[0]->dtor(ioc);
+		cic = list_entry(ioc->cic_list.first, struct cfq_io_context,
+								cic_list);
+		cic->dtor(ioc);
+	}
 }
 
 /*
@@ -57,18 +53,16 @@ EXPORT_SYMBOL(put_io_context);
 
 static void cfq_exit(struct io_context *ioc)
 {
-	struct cfq_io_context *cic[1];
-	int r;
-
 	rcu_read_lock();
-	/*
-	 * See comment for cfq_dtor()
-	 */
-	r = radix_tree_gang_lookup(&ioc->radix_root, (void **) cic, 0, 1);
-	rcu_read_unlock();
 
-	if (r > 0)
-		cic[0]->exit(ioc);
+	if (!hlist_empty(&ioc->cic_list)) {
+		struct cfq_io_context *cic;
+
+		cic = list_entry(ioc->cic_list.first, struct cfq_io_context,
+								cic_list);
+		cic->exit(ioc);
+	}
+	rcu_read_unlock();
 }
 
 /* Called by the exitting task */
@@ -105,6 +99,7 @@ struct io_context *alloc_io_context(gfp_t gfp_flags, int node)
 		ret->nr_batch_requests = 0; /* because this is 0 */
 		ret->aic = NULL;
 		INIT_RADIX_TREE(&ret->radix_root, GFP_ATOMIC | __GFP_HIGH);
+		INIT_HLIST_HEAD(&ret->cic_list);
 		ret->ioc_data = NULL;
 	}
 
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index ca198e6..62eda3f 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -1145,38 +1145,19 @@ static void cfq_put_queue(struct cfq_queue *cfqq)
 /*
  * Call func for each cic attached to this ioc. Returns number of cic's seen.
  */
-#define CIC_GANG_NR	16
 static unsigned int
 call_for_each_cic(struct io_context *ioc,
 		  void (*func)(struct io_context *, struct cfq_io_context *))
 {
-	struct cfq_io_context *cics[CIC_GANG_NR];
-	unsigned long index = 0;
-	unsigned int called = 0;
-	int nr;
+	struct cfq_io_context *cic;
+	struct hlist_node *n;
+	int called = 0;
 
 	rcu_read_lock();
-
-	do {
-		int i;
-
-		/*
-		 * Perhaps there's a better way - this just gang lookups from
-		 * 0 to the end, restarting after each CIC_GANG_NR from the
-		 * last key + 1.
-		 */
-		nr = radix_tree_gang_lookup(&ioc->radix_root, (void **) cics,
-						index, CIC_GANG_NR);
-		if (!nr)
-			break;
-
-		called += nr;
-		index = 1 + (unsigned long) cics[nr - 1]->key;
-
-		for (i = 0; i < nr; i++)
-			func(ioc, cics[i]);
-	} while (nr == CIC_GANG_NR);
-
+	hlist_for_each_entry_rcu(cic, n, &ioc->cic_list, cic_list) {
+		func(ioc, cic);
+		called++;
+	}
 	rcu_read_unlock();
 
 	return called;
@@ -1190,6 +1171,7 @@ static void cic_free_func(struct io_context *ioc, struct cfq_io_context *cic)
 
 	spin_lock_irqsave(&ioc->lock, flags);
 	radix_tree_delete(&ioc->radix_root, cic->dead_key);
+	hlist_del_rcu(&cic->cic_list);
 	spin_unlock_irqrestore(&ioc->lock, flags);
 
 	kmem_cache_free(cfq_ioc_pool, cic);
@@ -1280,6 +1262,7 @@ cfq_alloc_io_context(struct cfq_data *cfqd, gfp_t gfp_mask)
 	if (cic) {
 		cic->last_end_request = jiffies;
 		INIT_LIST_HEAD(&cic->queue_list);
+		INIT_HLIST_NODE(&cic->cic_list);
 		cic->dtor = cfq_free_io_context;
 		cic->exit = cfq_exit_io_context;
 		elv_ioc_count_inc(ioc_count);
@@ -1501,6 +1484,7 @@ cfq_drop_dead_cic(struct cfq_data *cfqd, struct io_context *ioc,
 		rcu_assign_pointer(ioc->ioc_data, NULL);
 
 	radix_tree_delete(&ioc->radix_root, (unsigned long) cfqd);
+	hlist_del_rcu(&cic->cic_list);
 	spin_unlock_irqrestore(&ioc->lock, flags);
 
 	cfq_cic_free(cic);
@@ -1561,6 +1545,7 @@ static int cfq_cic_link(struct cfq_data *cfqd, struct io_context *ioc,
 		spin_lock_irqsave(&ioc->lock, flags);
 		ret = radix_tree_insert(&ioc->radix_root,
 						(unsigned long) cfqd, cic);
+		hlist_add_head_rcu(&cic->cic_list, &ioc->cic_list);
 		spin_unlock_irqrestore(&ioc->lock, flags);
 
 		radix_tree_preload_end();
diff --git a/include/linux/iocontext.h b/include/linux/iocontext.h
index 593b222..1b4ccf2 100644
--- a/include/linux/iocontext.h
+++ b/include/linux/iocontext.h
@@ -50,6 +50,7 @@ struct cfq_io_context {
 	sector_t seek_mean;
 
 	struct list_head queue_list;
+	struct hlist_node cic_list;
 
 	void (*dtor)(struct io_context *); /* destructor */
 	void (*exit)(struct io_context *); /* called on task exit */
@@ -77,6 +78,7 @@ struct io_context {
 
 	struct as_io_context *aic;
 	struct radix_tree_root radix_root;
+	struct hlist_head cic_list;
 	void *ioc_data;
 };
 

-- 
Jens Axboe


  reply	other threads:[~2008-02-19  8:36 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-15 21:23 Linux 2.6.25-rc2 Linus Torvalds
2008-02-16  2:08 ` Rafael J. Wysocki
2008-02-16  5:44 ` [BUG] Linux 2.6.25-rc2 - Kernel Ooops while running dbench Kamalesh Babulal
2008-02-18 12:59   ` Andrew Morton
2008-02-18 12:59     ` Andrew Morton
2008-02-18 14:25     ` Jeff Garzik
2008-02-18 16:11       ` Frans Pop
2008-02-18 16:11         ` Frans Pop
2008-03-03 11:51     ` Pekka Enberg
2008-03-03 11:51       ` Pekka Enberg
2008-03-04  4:03       ` Kamalesh Babulal
2008-03-04  4:03         ` Kamalesh Babulal
2008-02-16  6:10 ` [BUG] Linux 2.6.25-rc2 - Regression from 2.6.24-rc1-git1 softlockup while bootup on powerpc Kamalesh Babulal
2008-02-16  6:10   ` Kamalesh Babulal
2008-02-17 19:29   ` Jens Axboe
2008-02-17 19:29     ` Jens Axboe
2008-02-19  8:04     ` KAMEZAWA Hiroyuki
2008-02-19  8:04       ` KAMEZAWA Hiroyuki
2008-02-19  8:36       ` Jens Axboe [this message]
2008-02-19  8:36         ` Jens Axboe
2008-02-19  8:47         ` KAMEZAWA Hiroyuki
2008-02-19  8:47           ` KAMEZAWA Hiroyuki
2008-02-19  8:58           ` Jens Axboe
2008-02-19  8:58             ` Jens Axboe
2008-02-19  9:07             ` KAMEZAWA Hiroyuki
2008-02-19  9:07               ` KAMEZAWA Hiroyuki
2008-02-19  9:09               ` Jens Axboe
2008-02-19  9:09                 ` Jens Axboe
2008-02-19  9:02         ` KAMEZAWA Hiroyuki
2008-02-19  9:02           ` KAMEZAWA Hiroyuki
2008-02-19  9:01           ` Jens Axboe
2008-02-19  9:01             ` Jens Axboe
2008-02-19 13:19         ` Kamalesh Babulal
2008-02-19 13:19           ` Kamalesh Babulal
2008-02-22  7:24         ` Andrew Morton
2008-02-22  7:24           ` Andrew Morton
2008-02-22  7:40           ` Jens Axboe
2008-02-22  7:40             ` Jens Axboe
2008-02-17 20:08   ` Rafael J. Wysocki
2008-02-17 20:08     ` Rafael J. Wysocki
2008-02-16 16:52 ` Linux 2.6.25-rc2 Jan Engelhardt
2008-02-16 19:14 ` Linux 2.6.25-rc2 regression: LVM cannot find volume group Tilman Schmidt
2008-02-16 20:12   ` Alan Cox
2008-02-16 22:37     ` Jiri Slaby
2008-02-18  0:57       ` Tilman Schmidt
2008-02-18  1:22         ` Jeff Chua
2008-02-18 10:35           ` Tilman Schmidt
2008-02-19  1:53       ` Alasdair G Kergon
2008-02-19  8:56         ` Tilman Schmidt
2008-02-16 21:38 ` Linux 2.6.25-rc2 Torsten Kaiser
2008-02-17 20:25   ` Rafael J. Wysocki
2008-02-17 21:32     ` Torsten Kaiser
2008-02-18 23:54   ` Linus Torvalds
2008-02-19  6:44     ` Torsten Kaiser
2008-02-19  6:11   ` Ingo Molnar
2008-02-19  6:54     ` Torsten Kaiser
2008-02-19  7:21       ` Pekka Enberg
2008-02-19 10:27         ` Ingo Molnar
2008-02-19 10:45           ` Pekka Enberg
2008-02-19 13:02           ` Mathieu Desnoyers
2008-02-19 14:00             ` Ingo Molnar
2008-02-19 14:02         ` Mathieu Desnoyers
2008-02-19 14:21           ` Pekka Enberg
2008-02-19 14:38             ` Pekka Enberg
2008-02-19 14:55               ` Ingo Molnar
2008-02-19 14:57                 ` Ingo Molnar
2008-02-19 15:54                   ` Pekka Enberg
2008-02-19 15:52                 ` Pekka Enberg
2008-02-20  0:36                   ` Zhang, Yanmin
2008-02-20  2:08                     ` Zhang, Yanmin
2008-02-20  6:53                       ` Zhang, Yanmin
2008-02-20  7:10                         ` Pekka Enberg
2008-02-19 16:20               ` Linus Torvalds
2008-02-19 16:45                 ` Ingo Molnar
2008-02-19 16:48                   ` Ingo Molnar
2008-02-19 19:27                 ` Torsten Kaiser
2008-02-19 20:08             ` Mathieu Desnoyers
2008-02-27 23:32               ` Christoph Lameter
2008-02-28  1:57                 ` Andrew Morton
2008-02-28  2:43                   ` Christoph Lameter
2008-02-28  8:14                   ` Ingo Molnar
2008-02-28 11:15                     ` Alan Cox
2008-02-28 11:13                   ` Jiri Kosina
2008-02-19 16:27           ` Eric Dumazet
2008-02-19 16:38             ` Linus Torvalds
2008-02-19 20:03             ` Mathieu Desnoyers
2008-02-27 23:34               ` Christoph Lameter
2008-02-28  5:55                 ` [PATCH] Implement slub fastpath in terms of freebase and freeoffset Mathieu Desnoyers
2008-02-28 19:08                   ` Christoph Lameter
2008-02-28 23:25                     ` Mathieu Desnoyers
2008-02-29  0:57                       ` Christoph Lameter
2008-02-29  1:56                         ` Mathieu Desnoyers
2008-02-29  2:12                           ` Christoph Lameter
2008-02-29  3:32                             ` Mathieu Desnoyers
2008-02-29  5:11                               ` Christoph Lameter
2008-02-29 13:03                                 ` Mathieu Desnoyers
2008-02-29 19:57                                   ` Christoph Lameter
2008-02-29 13:28                                 ` [PATCH] Slub Freeoffset check overflow Mathieu Desnoyers
2008-03-04  6:17                                   ` [PATCH] Slub Freeoffset check overflow (updated) Mathieu Desnoyers
2008-03-04  7:15                                     ` Christoph Lameter
2008-02-27 23:32             ` Linux 2.6.25-rc2 Christoph Lameter
2008-02-19 18:39           ` Torsten Kaiser

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=20080219083633.GN23197@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=kamalesh@linux.vnet.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mingo@elte.hu \
    --cc=vatsa@linux.vnet.ibm.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.