Sounds like you need a priority class besides sync and async.


--

[ message continues ]

There's BIO_META now as well, which I was testing at the same time
as RT priority. Marking all the metadata I/O as BIO_META did help,
but once again I never got to determining if that was a result of
the different tagging or the priority increase.

However, given that only CFQ understand BIO_META, I suspect that
changing the way XFS uses BIO_SYNC to be a combination of BIO_META
and BIO_SYNC would cause significant regressions on other
schedulers.....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
--

[ message continues ]

What exactly do you want META to mean?  Strict prioritisation over
all other non-META requests, or just more frequent and/or larger

That shouldn't be a problem.  noop doesn't care about any of that stuff,
and deadline doesn't care about BIO_SYNC (more on that below).  If the
bios that use META are a subset of those that currently use SYNC, then
we can temporarily change AS to treat META and SYNC equally.  Only CFQ
would change in behaviour.

So deadline should probably support BIO_SYNC... below is a patch to do
that.  It doesn't have much of an effect on postmark or compilebench on
a single spindle, but I'm guessing that's not the workload or hardware
that is expected to benefit.


---

Subject: [PATCH] deadline-iosched: support SYNC bio/request flag

Support sync/async requests in deadline rather than read/write, as is
done in AS and CFQ.

Signed-off-by: Aaron Carroll <aaronc@gelato.unsw.edu.au>
---
 block/deadline-iosched.c |   63 ++++++++++++++++++++++++---------------------
 1 files changed, 34 insertions(+), 29 deletions(-)

diff --git a/block/deadline-iosched.c b/block/deadline-iosched.c
index 342448c..b2cfd47 100644
--- a/block/deadline-iosched.c
+++ b/block/deadline-iosched.c
@@ -23,6 +23,11 @@ static const int writes_starved = 2;    /* max times reads can starve a write */
 static const int fifo_batch = 16;       /* # of sequential requests treated as one
 				     by the above parameters. For throughput. */
 
+enum {
+	REQ_ASYNC,
+	REQ_SYNC,
+};
+
 struct deadline_data {
 	/*
 	 * run time data
@@ -53,7 +58,7 @@ struct deadline_data {
 
 static void deadline_move_request(struct deadline_data *, struct request *);
 
-#define RQ_RB_ROOT(dd, rq)	(&(dd)->sort_list[rq_data_dir((rq))])
+#define RQ_RB_ROOT(dd, rq)	(&(dd)->sort_list[rq_is_sync((rq))])
 
 /*
  * get the request after `rq' in sector-sorted order
@@ -86,7 +91,7 @@ retry:
 static inline void
 deadline_del_rq_rb(struct deadline_data *dd, struct request *rq)
 {
-	const int data_dir = ...
[ message continues ]

The real question is "what was it supposed to mean"? AFAICT, it was
added to a couple of filesystems to be used to tag superblock read
I/O. Why - I don't know - there's a distinct lack of documentation
surrounding these bio flags. :/

Realistically, I'm not sure that having a separate queue for
BIO_META will buy us anything, given that noop is quite often the
fastest scheduler for XFS because it enables interleaved metadata
I/O to be merged with data I/O. Like I said, I was not able to spend
the time to determine exactly how BIO_META affected I/O patterns, so
I can't really comment on whether it is really necessary or not.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
--

[ message continues ]

It was added to be able to differentiate between data and meta data IO

There's no seperate queue for meta data IO anywhere. CFQ will give
_slight_ preference to meta data IO as a side effect, preferring the
meta IO for otherwise same IO in what to serve next in the same queue.
And it will not allow preemption of a meta data IO for a data IO.

So using meta should not yield any important boosts by itself.

-- 
Jens Axboe

--

[ message continues ]

Which means that performance increase I saw on CFQ was a result of
removing the BIO_SYNC tagging "optimisation" XFS uses for metadata,
not from adding BIO_META.....

Could you please document what these tags actually mean and do
so that other people don't get as confused as me about this
stuff....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
--

[ message continues ]

Sure, I've added such a patch for 2.6.28.

-- 
Jens Axboe

--

[ message continues ]