From: Vivek Goyal <vgoyal@redhat.com>
To: linux-kernel@vger.kernel.org, jens.axboe@oracle.com
Cc: containers@lists.linux-foundation.org, dm-devel@redhat.com,
nauman@google.com, dpshah@google.com, lizf@cn.fujitsu.com,
mikew@google.com, fchecconi@gmail.com, paolo.valente@unimore.it,
ryov@valinux.co.jp, fernando@oss.ntt.co.jp,
s-uchida@ap.jp.nec.com, taka@valinux.co.jp,
guijianfeng@cn.fujitsu.com, jmoyer@redhat.com,
dhaval@linux.vnet.ibm.com, balbir@linux.vnet.ibm.com,
righi.andrea@gmail.com, m-ikeda@ds.jp.nec.com, agk@redhat.com,
vgoyal@redhat.com, akpm@linux-foundation.org,
peterz@infradead.org, jmarchan@redhat.com,
torvalds@linux-foundation.org, mingo@elte.hu, riel@redhat.com
Subject: [PATCH 03/28] io-controller: Keep a cache of recently expired queues
Date: Thu, 24 Sep 2009 15:25:07 -0400 [thread overview]
Message-ID: <1253820332-10246-4-git-send-email-vgoyal@redhat.com> (raw)
In-Reply-To: <1253820332-10246-1-git-send-email-vgoyal@redhat.com>
o Currently once a queue uses its slice and it is empty, we remove it from the
service tree and when a new request comes in it is queued at the end of tree.
It works as long as there are only queue or only groups at same level but if
there is a mix of queue and group, there can be fairness issue. For example,
consider following case.
root
/ \
T1 G1
|
T2
T1 and T2 are two tasks with prio 0 and 7 respectively and G1 is the group
with weight 900.
Task T1 prio 0 is mapped to weight 900 and it will get slice length of 180ms
and then queue will expire and will be put after G1. (Note, in case of reader
most liekly next request will come after queue expiry hence queue will be
deleted and once the request comes in again, it will added to tree fresh. A
fresh queue is added at the end of the tree. So it will be put after G1.).
Now G1 will get to run (effectivly T2 will run), T2 has prio 7, which will
map to weight 200 and get slice length of 40ms and will expire after that. Now
G1 will a new vtime which is effectively charge of 40ms.
Now to get fairness G1 should run more but instead T1 will be running as we
gave it a vtime, same as G1.
The core issue here is that for readers, when slice expires, queue is empty
and not backlogged hence it gets deleted from the tree. Because CFQ only
operates in flat mode, it did a smart thing and did not keep a track of
history. Instead it provides slice lenghts according to prio and if in one
round of dispatch one gets fairness it is fine, otherwise upon queue expiry
you will be placed at the end of service tree.
This does not work in hierarchical setups where group's slice lenght is
determined not by group' weight but by the weight of the queue which will
run under the group.
Hence we need to keep track of histroy and assign a new vtime based on disk
time used by the current queue at the time of expiry.
But here io scheduler is little different from CFS that at the time of expiry
most of the time reader's queue is empty. So one will end up deleting it from
the service tree and next request comes with-in 1 ms and it gets into the tree
again like a new process.
So we need to keep track of process io queue's vdisktime, even it after got
deleted from io scheduler's service tree and use that same vdisktime if that
queue gets backlogged again. But trusting a ioq's vdisktime is bad because
it can lead to issues if a service tree min_vtime wrap around takes place
between two requests of the queue. (Agreed that it can be not that easy to
hit but it is possible).
Hence, keep a cache of io queues serviced recently and when a queue gets
backlogged, if it is found in cache, use that vdisktime otherwise assign
a new vdisktime. This cache of io queues (idle tree), is basically the idea
implemented by BFQ guys. I had gotten rid of idle trees in V9 and now I am
bringing it back. (Now I understand it better. :-)).
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Rik van Riel <riel@redhat.com>
---
block/elevator-fq.c | 188 ++++++++++++++++++++++++++++++++++++++++++++++-----
block/elevator-fq.h | 7 ++
2 files changed, 179 insertions(+), 16 deletions(-)
diff --git a/block/elevator-fq.c b/block/elevator-fq.c
index d98fa42..8343397 100644
--- a/block/elevator-fq.c
+++ b/block/elevator-fq.c
@@ -21,6 +21,8 @@
#define ELV_SLICE_SCALE (500)
#define ELV_SERVICE_SHIFT 20
+static void check_idle_tree_release(struct io_service_tree *st);
+
static inline struct io_queue *ioq_of(struct io_entity *entity)
{
if (entity->my_sd == NULL)
@@ -78,6 +80,11 @@ elv_prio_to_slice(struct elv_fq_data *efqd, struct io_queue *ioq)
return elv_weight_slice(efqd, elv_ioq_sync(ioq), ioq->entity.weight);
}
+static inline int vdisktime_gt(u64 a, u64 b)
+{
+ return (s64)(a - b) > 0;
+}
+
static inline u64 max_vdisktime(u64 min_vdisktime, u64 vdisktime)
{
s64 delta = (s64)(vdisktime - min_vdisktime);
@@ -114,6 +121,7 @@ static void update_min_vdisktime(struct io_service_tree *st)
}
st->min_vdisktime = max_vdisktime(st->min_vdisktime, vdisktime);
+ check_idle_tree_release(st);
}
static inline struct io_entity *parent_entity(struct io_entity *entity)
@@ -167,27 +175,46 @@ static void place_entity(struct io_service_tree *st, struct io_entity *entity,
struct rb_node *parent;
struct io_entity *entry;
int nr_active = st->nr_active - 1;
+ struct io_queue *ioq = ioq_of(entity);
+ int sync = 1;
+
+ if (ioq)
+ sync = elv_ioq_sync(ioq);
+
+ if (add_front || !nr_active) {
+ vdisktime = st->min_vdisktime;
+ goto done;
+ }
+
+ if (sync && entity->vdisktime
+ && vdisktime_gt(entity->vdisktime, st->min_vdisktime)) {
+ /* vdisktime still in future. Use old vdisktime */
+ vdisktime = entity->vdisktime;
+ goto done;
+ }
/*
- * Currently put entity at the end of last entity. This probably will
- * require adjustments as we move along
+ * Effectively a new queue. Assign sync queue a lower vdisktime so
+ * we can achieve better latencies for small file readers. For async
+ * queues, put them at the end of the existing queue.
+ * Group entities are always considered sync.
*/
- if (io_entity_class_idle(entity)) {
- vdisktime = elv_delta_fair(ELV_IDLE_DELAY, entity);
- parent = rb_last(&st->active);
- if (parent) {
- entry = rb_entry(parent, struct io_entity, rb_node);
- vdisktime += entry->vdisktime;
- }
- } else if (!add_front && nr_active) {
- parent = rb_last(&st->active);
- if (parent) {
- entry = rb_entry(parent, struct io_entity, rb_node);
- vdisktime = entry->vdisktime;
- }
- } else
+ if (sync) {
vdisktime = st->min_vdisktime;
+ goto done;
+ }
+ /*
+ * Put entity at the end of the tree. Effectively async queues use
+ * this path.
+ */
+ parent = rb_last(&st->active);
+ if (parent) {
+ entry = rb_entry(parent, struct io_entity, rb_node);
+ vdisktime = entry->vdisktime;
+ } else
+ vdisktime = st->min_vdisktime;
+done:
entity->vdisktime = max_vdisktime(st->min_vdisktime, vdisktime);
}
@@ -200,6 +227,122 @@ static inline void io_entity_update_prio(struct io_entity *entity)
*/
init_io_entity_service_tree(entity, parent_entity(entity));
entity->ioprio_changed = 0;
+
+ /*
+ * Assign this entity a fresh vdisktime instead of using
+ * previous one as prio class will lead to service tree
+ * change and this vdisktime will not be valid on new
+ * service tree.
+ *
+ * TODO: Handle the case of only prio change.
+ */
+ entity->vdisktime = 0;
+ }
+}
+
+static void
+__dequeue_io_entity_idle(struct io_service_tree *st, struct io_entity *entity)
+{
+ if (st->rb_leftmost_idle == &entity->rb_node) {
+ struct rb_node *next_node;
+
+ next_node = rb_next(&entity->rb_node);
+ st->rb_leftmost_idle = next_node;
+ }
+
+ rb_erase(&entity->rb_node, &st->idle);
+ RB_CLEAR_NODE(&entity->rb_node);
+}
+
+static void dequeue_io_entity_idle(struct io_entity *entity)
+{
+ struct io_queue *ioq = ioq_of(entity);
+
+ __dequeue_io_entity_idle(entity->st, entity);
+ entity->on_idle_st = 0;
+ if (ioq)
+ elv_put_ioq(ioq);
+}
+
+static void
+__enqueue_io_entity_idle(struct io_service_tree *st, struct io_entity *entity)
+{
+ struct rb_node **node = &st->idle.rb_node;
+ struct rb_node *parent = NULL;
+ struct io_entity *entry;
+ int leftmost = 1;
+
+ while (*node != NULL) {
+ parent = *node;
+ entry = rb_entry(parent, struct io_entity, rb_node);
+
+ if (vdisktime_gt(entry->vdisktime, entity->vdisktime))
+ node = &parent->rb_left;
+ else {
+ node = &parent->rb_right;
+ leftmost = 0;
+ }
+ }
+
+ /*
+ * Maintain a cache of leftmost tree entries (it is frequently
+ * used)
+ */
+ if (leftmost)
+ st->rb_leftmost_idle = &entity->rb_node;
+
+ rb_link_node(&entity->rb_node, parent, node);
+ rb_insert_color(&entity->rb_node, &st->idle);
+}
+
+static void enqueue_io_entity_idle(struct io_entity *entity)
+{
+ struct io_queue *ioq = ioq_of(entity);
+ struct io_group *parent_iog;
+
+ /*
+ * Don't put an entity on idle tree if it has been marked for deletion.
+ * We are not expecting more io from this entity. No need to cache it
+ */
+
+ if (entity->exiting)
+ return;
+
+ /*
+ * If parent group is exiting, don't put on idle tree. May be task got
+ * moved to a different cgroup and original cgroup got deleted
+ */
+ parent_iog = iog_of(parent_entity(entity));
+ if (parent_iog->entity.exiting)
+ return;
+
+ if (ioq)
+ elv_get_ioq(ioq);
+ __enqueue_io_entity_idle(entity->st, entity);
+ entity->on_idle_st = 1;
+}
+
+static void check_idle_tree_release(struct io_service_tree *st)
+{
+ struct io_entity *leftmost;
+
+ if (!st->rb_leftmost_idle)
+ return;
+
+ leftmost = rb_entry(st->rb_leftmost_idle, struct io_entity, rb_node);
+
+ if (vdisktime_gt(st->min_vdisktime, leftmost->vdisktime))
+ dequeue_io_entity_idle(leftmost);
+}
+
+static void flush_idle_tree(struct io_service_tree *st)
+{
+ struct io_entity *entity;
+
+ while (st->rb_leftmost_idle) {
+ entity = rb_entry(st->rb_leftmost_idle, struct io_entity,
+ rb_node);
+ dequeue_io_entity_idle(entity);
}
}
@@ -235,6 +378,9 @@ static void dequeue_io_entity(struct io_entity *entity)
entity->on_st = 0;
st->nr_active--;
sd->nr_active--;
+
+ if (vdisktime_gt(entity->vdisktime, st->min_vdisktime))
+ enqueue_io_entity_idle(entity);
}
static void
@@ -276,6 +422,16 @@ static void enqueue_io_entity(struct io_entity *entity)
struct io_service_tree *st;
struct io_sched_data *sd = io_entity_sched_data(entity);
+ if (entity->on_idle_st)
+ dequeue_io_entity_idle(entity);
+ else
+ /*
+ * This entity was not in idle tree cache. Zero out vdisktime
+ * so that we don't rely on old vdisktime instead assign a
+ * fresh one.
+ */
+ entity->vdisktime = 0;
+
io_entity_update_prio(entity);
st = entity->st;
st->nr_active++;
diff --git a/block/elevator-fq.h b/block/elevator-fq.h
index 868e035..ee46a47 100644
--- a/block/elevator-fq.h
+++ b/block/elevator-fq.h
@@ -28,6 +28,10 @@ struct io_service_tree {
u64 min_vdisktime;
struct rb_node *rb_leftmost;
unsigned int nr_active;
+
+ /* A cache of io entities which were served and expired */
+ struct rb_root idle;
+ struct rb_node *rb_leftmost_idle;
};
struct io_sched_data {
@@ -39,9 +43,12 @@ struct io_sched_data {
struct io_entity {
struct rb_node rb_node;
int on_st;
+ int on_idle_st;
u64 vdisktime;
unsigned int weight;
struct io_entity *parent;
+ /* This io entity (queue or group) has been marked for deletion */
+ unsigned int exiting;
struct io_sched_data *my_sd;
struct io_service_tree *st;
--
1.6.0.6
next prev parent reply other threads:[~2009-09-24 19:26 UTC|newest]
Thread overview: 177+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-24 19:25 IO scheduler based IO controller V10 Vivek Goyal
2009-09-24 19:25 ` [PATCH 01/28] io-controller: Documentation Vivek Goyal
2009-09-24 19:25 ` [PATCH 02/28] io-controller: Core of the elevator fair queuing Vivek Goyal
2009-09-24 19:25 ` Vivek Goyal [this message]
2009-09-24 19:25 ` [PATCH 04/28] io-controller: Common flat fair queuing code in elevaotor layer Vivek Goyal
2009-09-24 19:25 ` [PATCH 05/28] io-controller: Modify cfq to make use of flat elevator fair queuing Vivek Goyal
2009-09-24 19:25 ` [PATCH 06/28] io-controller: Core scheduler changes to support hierarhical scheduling Vivek Goyal
2009-09-24 19:25 ` [PATCH 07/28] io-controller: cgroup related changes for hierarchical group support Vivek Goyal
2009-09-24 19:25 ` [PATCH 08/28] io-controller: Common hierarchical fair queuing code in elevaotor layer Vivek Goyal
2009-09-24 19:25 ` [PATCH 09/28] io-controller: cfq changes to use " Vivek Goyal
2009-09-24 19:25 ` [PATCH 10/28] io-controller: Export disk time used and nr sectors dipatched through cgroups Vivek Goyal
2009-09-24 19:25 ` [PATCH 11/28] io-controller: Debug hierarchical IO scheduling Vivek Goyal
2009-09-24 19:25 ` [PATCH 12/28] io-controller: Introduce group idling Vivek Goyal
2009-09-24 19:25 ` [PATCH 13/28] io-controller: Implement wait busy for io queues Vivek Goyal
2009-09-24 19:25 ` [PATCH 14/28] io-controller: Keep track of late preemptions Vivek Goyal
2009-09-24 19:25 ` [PATCH 15/28] io-controller: Allow CFQ specific extra preemptions Vivek Goyal
2009-09-25 6:24 ` Gui Jianfeng
2009-09-24 19:25 ` [PATCH 16/28] io-controller: Wait for requests to complete from last queue before new queue is scheduled Vivek Goyal
2009-09-24 19:25 ` [PATCH 17/28] io-controller: Separate out queue and data Vivek Goyal
2009-09-24 19:25 ` [PATCH 18/28] io-conroller: Prepare elevator layer for single queue schedulers Vivek Goyal
2009-09-24 19:25 ` [PATCH 19/28] io-controller: Avoid expiring ioq for single ioq scheduler if only root group Vivek Goyal
2009-09-24 19:25 ` [PATCH 20/28] io-controller: noop changes for hierarchical fair queuing Vivek Goyal
2009-09-24 19:25 ` [PATCH 21/28] io-controller: deadline " Vivek Goyal
2009-09-24 19:25 ` [PATCH 22/28] io-controller: anticipatory " Vivek Goyal
2009-09-24 19:25 ` [PATCH 23/28] io-controller: blkio_cgroup patches from Ryo to track async bios Vivek Goyal
2009-09-24 19:25 ` [PATCH 24/28] io-controller: map async requests to appropriate cgroup Vivek Goyal
2009-09-24 19:25 ` [PATCH 25/28] io-controller: Per cgroup request descriptor support Vivek Goyal
2009-09-24 19:25 ` [PATCH 26/28] io-controller: Per io group bdi congestion interface Vivek Goyal
2009-09-24 19:25 ` [PATCH 27/28] io-controller: Support per cgroup per device weights and io class Vivek Goyal
2009-09-24 19:25 ` [PATCH 28/28] io-controller: debug elevator fair queuing support Vivek Goyal
2009-09-24 21:33 ` IO scheduler based IO controller V10 Andrew Morton
2009-09-25 1:09 ` KAMEZAWA Hiroyuki
2009-09-25 1:18 ` KAMEZAWA Hiroyuki
2009-09-25 5:29 ` Balbir Singh
2009-09-25 7:09 ` Ryo Tsuruta
2009-09-25 4:14 ` Vivek Goyal
2009-09-25 5:04 ` Vivek Goyal
2009-09-25 9:07 ` Ryo Tsuruta
2009-09-25 14:33 ` Vivek Goyal
2009-09-28 7:30 ` Ryo Tsuruta
2009-09-25 15:04 ` Rik van Riel
2009-09-28 7:38 ` Ryo Tsuruta
2009-10-08 4:42 ` More performance numbers (Was: Re: IO scheduler based IO controller V10) Vivek Goyal
2009-10-08 8:34 ` Andrea Righi
2009-10-10 19:53 ` Performance numbers with IO throttling patches " Vivek Goyal
2009-10-10 22:27 ` Andrea Righi
2009-10-11 12:32 ` Vivek Goyal
2009-10-12 21:11 ` Vivek Goyal
2009-10-17 15:18 ` Andrea Righi
2009-09-25 2:20 ` IO scheduler based IO controller V10 Ulrich Lukas
2009-09-25 20:26 ` Vivek Goyal
2009-09-26 14:51 ` Mike Galbraith
2009-09-27 6:55 ` Mike Galbraith
2009-09-27 16:42 ` Jens Axboe
2009-09-27 18:15 ` Mike Galbraith
2009-09-28 4:04 ` Mike Galbraith
2009-09-28 5:55 ` Mike Galbraith
2009-09-28 17:48 ` Vivek Goyal
2009-09-28 18:24 ` Mike Galbraith
2009-09-30 19:58 ` Mike Galbraith
2009-09-30 20:05 ` Mike Galbraith
2009-09-30 20:24 ` Vivek Goyal
2009-10-01 7:33 ` Mike Galbraith
2009-10-01 18:58 ` Jens Axboe
2009-10-02 6:23 ` Mike Galbraith
2009-10-02 8:04 ` Jens Axboe
2009-10-02 8:53 ` Mike Galbraith
2009-10-02 9:00 ` Mike Galbraith
2009-10-02 9:55 ` Jens Axboe
2009-10-02 12:22 ` Mike Galbraith
2009-10-02 9:24 ` Ingo Molnar
2009-10-02 9:28 ` Jens Axboe
2009-10-02 14:24 ` Linus Torvalds
2009-10-02 14:45 ` Mike Galbraith
2009-10-02 14:57 ` Jens Axboe
2009-10-02 14:56 ` Jens Axboe
2009-10-02 15:14 ` Linus Torvalds
2009-10-02 16:01 ` jim owens
2009-10-02 17:11 ` Jens Axboe
2009-10-02 17:20 ` Ingo Molnar
2009-10-02 17:25 ` Jens Axboe
2009-10-02 17:28 ` Ingo Molnar
2009-10-02 17:37 ` Jens Axboe
2009-10-02 17:56 ` Ingo Molnar
2009-10-02 18:04 ` Jens Axboe
2009-10-02 18:22 ` Mike Galbraith
2009-10-02 18:26 ` Jens Axboe
2009-10-02 18:33 ` Mike Galbraith
2009-10-02 18:36 ` Theodore Tso
2009-10-02 18:45 ` Jens Axboe
2009-10-02 19:01 ` Ingo Molnar
2009-10-02 19:09 ` Jens Axboe
2009-10-02 18:13 ` Mike Galbraith
2009-10-02 18:19 ` Jens Axboe
2009-10-02 18:57 ` Mike Galbraith
2009-10-02 20:47 ` Mike Galbraith
2009-10-03 5:48 ` Mike Galbraith
2009-10-03 5:56 ` Mike Galbraith
2009-10-03 6:31 ` tweaking IO latency [was Re: IO scheduler based IO controller V10] Mike Galbraith
2009-10-03 7:24 ` IO scheduler based IO controller V10 Jens Axboe
2009-10-03 9:00 ` Mike Galbraith
2009-10-03 9:12 ` Corrado Zoccolo
2009-10-03 13:18 ` Jens Axboe
2009-10-03 13:17 ` Jens Axboe
2009-10-03 11:29 ` Vivek Goyal
2009-10-03 12:40 ` Do not overload dispatch queue (Was: Re: IO scheduler based IO controller V10) Vivek Goyal
2009-10-03 13:21 ` Jens Axboe
2009-10-03 13:56 ` Vivek Goyal
2009-10-03 14:02 ` Mike Galbraith
2009-10-03 14:28 ` Jens Axboe
2009-10-03 14:33 ` Mike Galbraith
2009-10-03 14:51 ` Mike Galbraith
2009-10-03 15:14 ` Jens Axboe
2009-10-03 15:57 ` Mike Galbraith
2009-10-03 17:35 ` Jens Axboe
2009-10-03 17:45 ` Linus Torvalds
2009-10-03 17:51 ` Jens Axboe
2009-10-03 19:07 ` Mike Galbraith
2009-10-03 19:11 ` Mike Galbraith
2009-10-03 19:23 ` Jens Axboe
2009-10-03 19:49 ` Mike Galbraith
2009-10-04 10:50 ` Mike Galbraith
2009-10-04 11:33 ` Mike Galbraith
2009-10-04 17:39 ` Jens Axboe
2009-10-04 18:23 ` Mike Galbraith
2009-10-04 18:38 ` Jens Axboe
2009-10-04 19:47 ` Mike Galbraith
2009-10-04 20:17 ` Jens Axboe
2009-10-04 22:15 ` Mike Galbraith
2009-10-03 13:57 ` Mike Galbraith
2009-10-03 7:20 ` IO scheduler based IO controller V10 Ingo Molnar
2009-10-03 7:25 ` Jens Axboe
2009-10-03 8:53 ` Mike Galbraith
2009-10-03 9:01 ` Corrado Zoccolo
2009-10-02 16:33 ` Ray Lee
2009-10-02 17:13 ` Jens Axboe
2009-10-02 16:22 ` Ingo Molnar
2009-10-02 9:36 ` Mike Galbraith
2009-10-02 16:37 ` Ingo Molnar
2009-10-02 18:08 ` Jens Axboe
2009-10-02 18:29 ` Mike Galbraith
2009-10-02 18:36 ` Jens Axboe
2009-09-27 17:00 ` Corrado Zoccolo
2009-09-28 14:56 ` Vivek Goyal
2009-09-28 15:35 ` Corrado Zoccolo
2009-09-28 17:14 ` Vivek Goyal
2009-09-29 7:10 ` Corrado Zoccolo
2009-09-28 17:51 ` Mike Galbraith
2009-09-28 18:18 ` Vivek Goyal
2009-09-28 18:53 ` Mike Galbraith
2009-09-29 7:14 ` Corrado Zoccolo
2009-09-29 5:55 ` Mike Galbraith
2009-09-29 0:37 ` Nauman Rafique
2009-09-29 3:22 ` Vivek Goyal
2009-09-29 9:56 ` Ryo Tsuruta
2009-09-29 10:49 ` Takuya Yoshikawa
2009-09-29 14:10 ` Vivek Goyal
2009-09-29 19:53 ` Nauman Rafique
2009-09-30 8:43 ` Ryo Tsuruta
2009-09-30 11:05 ` Vivek Goyal
2009-10-01 6:41 ` Ryo Tsuruta
2009-10-01 13:31 ` Vivek Goyal
2009-10-02 2:57 ` Vivek Goyal
2009-10-02 20:27 ` Munehiro Ikeda
2009-10-05 10:38 ` Ryo Tsuruta
2009-10-05 12:31 ` Vivek Goyal
2009-10-05 14:55 ` Ryo Tsuruta
2009-10-05 17:10 ` Vivek Goyal
2009-10-05 18:11 ` Nauman Rafique
2009-10-06 7:17 ` Ryo Tsuruta
2009-10-06 11:22 ` Vivek Goyal
2009-10-07 14:38 ` Ryo Tsuruta
2009-10-07 15:09 ` Vivek Goyal
2009-10-08 2:18 ` Ryo Tsuruta
2009-10-07 16:41 ` Rik van Riel
2009-10-08 10:22 ` Ryo Tsuruta
2009-09-30 3:11 ` Vivek Goyal
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=1253820332-10246-4-git-send-email-vgoyal@redhat.com \
--to=vgoyal@redhat.com \
--cc=agk@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=containers@lists.linux-foundation.org \
--cc=dhaval@linux.vnet.ibm.com \
--cc=dm-devel@redhat.com \
--cc=dpshah@google.com \
--cc=fchecconi@gmail.com \
--cc=fernando@oss.ntt.co.jp \
--cc=guijianfeng@cn.fujitsu.com \
--cc=jens.axboe@oracle.com \
--cc=jmarchan@redhat.com \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=m-ikeda@ds.jp.nec.com \
--cc=mikew@google.com \
--cc=mingo@elte.hu \
--cc=nauman@google.com \
--cc=paolo.valente@unimore.it \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=righi.andrea@gmail.com \
--cc=ryov@valinux.co.jp \
--cc=s-uchida@ap.jp.nec.com \
--cc=taka@valinux.co.jp \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome