io scheduler merges control

io scheduler merges control

[john smith]

IOPS-reported numbers for a test vary (more than 30% in my case) from one run to another depending on kernel io scheduler merges (reported in "Disk stats/merges=reads/writes") making it hard to measure/compare performance of block drivers, for instance.

I don't see any way to turn off kernel io scheduler merges (cfq or others)
and I'd ask if you would consider adding support for it, disabling the merges per individual device, using sys-fs maybe?

If you do, adding an option to fio for controlling the merges would be useful too,

thanks,
John



      

Re: io scheduler merges control

[Alan D. Brunelle]

On Thu, 2009-12-24 at 11:12 -0800, john smith wrote:
> IOPS-reported numbers for a test vary (more than 30% in my case) from one run to another depending on kernel io scheduler merges (reported in "Disk stats/merges=reads/writes") making it hard to measure/compare performance of block drivers, for instance.
> 
> I don't see any way to turn off kernel io scheduler merges (cfq or others)
> and I'd ask if you would consider adding support for it, disabling the merges per individual device, using sys-fs maybe?
> 
> If you do, adding an option to fio for controlling the merges would be useful too,
> 
> thanks,
> John

Hi John - 

FYI: there is /sys/block/*/queue/nomerges - when set to one ('echo 1
> /sys/block/<dsf>/queue/nomerges) - a lot of the merging attempts are
not performed. [Note, _some_ simple merge attempts _are_ still attempted
regardless of its setting...]

Regards,
Alan

Re: io scheduler merges control

[john smith]

Alan,

I've tried 'echo "1"> /sys/block/<dsf>/queue/nomerges' but fio/sequential-reads merges still occur and apparently they are only the simple ones that can't be disabled.

1) What can I change in the kernel to disable ALL the merges (including the simple ones)?
(I tried setting iosched_cfq.ops.elevator_merge_fn, elevator_merged_fn, elevator_merge_req_fn, elevator_allow_merge_fn = 0 but still fio reported merges)

2) One other question I have is why one driver benefits of the io scheduler merges and the other doesn't? 
(Note that HDD's don't have any other io activity - aside from fio - and both are doing the same 512B sequential reads)

3) The third question is why the number of fio reported "merge"(s) is greater than the number of the "ios"?

thanks,
John

--- On Mon, 1/4/10, Alan D. Brunelle <Alan.Brunelle@hp.com> wrote:

> From: Alan D. Brunelle <Alan.Brunelle@hp.com>
> Subject: Re: io scheduler merges control
> To: "john smith" <whalajam@yahoo.com>
> Cc: fio@vger.kernel.org
> Date: Monday, January 4, 2010, 6:34 AM
> On Thu, 2009-12-24 at 11:12 -0800,

> john smith wrote:
> > IOPS-reported numbers for a test vary (more than 30%
> in my case) from one run to another depending on kernel io
> scheduler merges (reported in "Disk
> stats/merges=reads/writes") making it hard to
> measure/compare performance of block drivers, for instance.
> > 
> > I don't see any way to turn off kernel io scheduler
> merges (cfq or others)
> > and I'd ask if you would consider adding support for
> it, disabling the merges per individual device, using sys-fs
> maybe?
> > 
> > If you do, adding an option to fio for controlling the
> merges would be useful too,
> > 
> > thanks,
> > John
> 
> Hi John - 
> 
> FYI: there is /sys/block/*/queue/nomerges - when set to one
> ('echo 1
> > /sys/block/<dsf>/queue/nomerges) - a lot of the
> merging attempts are
> not performed. [Note, _some_ simple merge attempts _are_
> still attempted
> regardless of its setting...]
> 
> Regards,
> Alan
> 
> --
> To unsubscribe from this list: send the line "unsubscribe
> fio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at� http://vger.kernel.org/majordomo-info.html
> 


      

Re: io scheduler merges control

[Alan D. Brunelle]

On Mon, 2010-01-04 at 17:53 -0800, john smith wrote:
> Alan,
> 
> I've tried 'echo "1"> /sys/block/<dsf>/queue/nomerges' but
> fio/sequential-reads merges still occur and apparently they are only
> the simple ones that can't be disabled.
> 
> 1) What can I change in the kernel to disable ALL the merges
> (including the simple ones)?
> (I tried setting iosched_cfq.ops.elevator_merge_fn,
> elevator_merged_fn, elevator_merge_req_fn, elevator_allow_merge_fn = 0
> but still fio reported merges)

Unfortunately, the "simple" ones were left in precisely because they
were (a) easy to do, and (b) were expected to happen often enough to
keep them in. Jens may be able to comment further.

I can look back to my original patch proposal (which includes nuking all
merge attempts) - basically: look at the code that follows "normerges"
and use the same test for the one-hit caching code will probably be
sufficient.

> 
> 2) One other question I have is why one driver benefits of the io
> scheduler merges and the other doesn't? 
> (Note that HDD's don't have any other io activity - aside from fio -
> and both are doing the same 512B sequential reads)

Are the I/O sizes the same (as reported by iostat)? It could simply be
that one driver/device is performing faster than the other? Would need
to get some good stat data from both drivers/devices to see what was
going on.


> 
> 3) The third question is why the number of fio reported "merge"(s) is
> greater than the number of the "ios"?

Not sure about 'fio's output, but in general: if you have 'N' I/O
submissions and these are merged down into 'M' I/Os, then you could have
a large 'N/M' value (which should be about the number of merges done).
For example, if you are doing 512 byte read/writes and these are merged
into 512 K I/Os, you'll have 1000 merges for each I/O performed.

Regards,
Alan

Re: io scheduler merges control

[Jens Axboe]

On Tue, Jan 05 2010, Alan D. Brunelle wrote:
> On Mon, 2010-01-04 at 17:53 -0800, john smith wrote:
> > Alan,
> > 
> > I've tried 'echo "1"> /sys/block/<dsf>/queue/nomerges' but
> > fio/sequential-reads merges still occur and apparently they are only
> > the simple ones that can't be disabled.
> > 
> > 1) What can I change in the kernel to disable ALL the merges
> > (including the simple ones)?
> > (I tried setting iosched_cfq.ops.elevator_merge_fn,
> > elevator_merged_fn, elevator_merge_req_fn, elevator_allow_merge_fn = 0
> > but still fio reported merges)
> 
> Unfortunately, the "simple" ones were left in precisely because they
> were (a) easy to do, and (b) were expected to happen often enough to
> keep them in. Jens may be able to comment further.

Right, they are both cheap and easy so they were kept. The goal with the
nomerges switch was to save CPU, so it'll still do cheap merges. I don't
think there's a use for disabling merges completely outside of device
testing and benchmarking, it's not a real world problem. That said, I do
occasionally hack that up as well for testing purposes. Perhaps we could
tweak nomerges to accept a '2' value as well, indicating that we don't
want any merges at all.

-- 
Jens Axboe

Re: io scheduler merges control

[john smith]

Jens,

--- On Mon, 1/11/10, Jens Axboe <jens.axboe@oracle.com> wrote:

> From: Jens Axboe <jens.axboe@oracle.com>
> Subject: Re: io scheduler merges control
> To: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
> Cc: "john smith" <whalajam@yahoo.com>, fio@vger.kernel.org
> Date: Monday, January 11, 2010, 5:54 AM
> On Tue, Jan 05 2010, Alan D. Brunelle
> wrote:
> > On Mon, 2010-01-04 at 17:53 -0800, john smith wrote:
> > > Alan,
> > > 
> > > I've tried 'echo "1">
> /sys/block/<dsf>/queue/nomerges' but
> > > fio/sequential-reads merges still occur and
> apparently they are only
> > > the simple ones that can't be disabled.
> > > 
> > > 1) What can I change in the kernel to disable ALL
> the merges
> > > (including the simple ones)?
> > > (I tried setting
> iosched_cfq.ops.elevator_merge_fn,
> > > elevator_merged_fn, elevator_merge_req_fn,
> elevator_allow_merge_fn = 0
> > > but still fio reported merges)
> > 
> > Unfortunately, the "simple" ones were left in
> precisely because they
> > were (a) easy to do, and (b) were expected to happen
> often enough to
> > keep them in. Jens may be able to comment further.
> 
> Right, they are both cheap and easy so they were kept. The
> goal with the
> nomerges switch was to save CPU, so it'll still do cheap
> merges. I don't
> think there's a use for disabling merges completely outside
> of device
> testing and benchmarking, it's not a real world problem.
> That said, I do
> occasionally hack that up as well for testing purposes.
> Perhaps we could
> tweak nomerges to accept a '2' value as well, indicating
> that we don't
> want any merges at all.
 
That would be useful, I'd like to have a way to monitor this (nomerges='2') addition.

I have one more question that you can shed some light on: 
how is that there are more merges for a faster driver than for a slower one (giving the same IO patern)?

I would think that, given that both drivers have the same queue depth, the slower the driver (the higher completion latency), the more merges can be done by the elevator (I'm sure is more complex than that).

Probably there is a description of this process somewhere, just couldn't find it, and biodoc.txt wasn't clear about it.

Thanks,
John


> -- 
> Jens Axboe
> 
> 


      

Re: io scheduler merges control

[Alan D. Brunelle]

[-- Attachment #1: Type: text/plain, Size: 1843 bytes --]

On Mon, 2010-01-11 at 14:54 +0100, Jens Axboe wrote:
> On Tue, Jan 05 2010, Alan D. Brunelle wrote:
> > On Mon, 2010-01-04 at 17:53 -0800, john smith wrote:
> > > Alan,
> > > 
> > > I've tried 'echo "1"> /sys/block/<dsf>/queue/nomerges' but
> > > fio/sequential-reads merges still occur and apparently they are only
> > > the simple ones that can't be disabled.
> > > 
> > > 1) What can I change in the kernel to disable ALL the merges
> > > (including the simple ones)?
> > > (I tried setting iosched_cfq.ops.elevator_merge_fn,
> > > elevator_merged_fn, elevator_merge_req_fn, elevator_allow_merge_fn = 0
> > > but still fio reported merges)
> > 
> > Unfortunately, the "simple" ones were left in precisely because they
> > were (a) easy to do, and (b) were expected to happen often enough to
> > keep them in. Jens may be able to comment further.
> 
> Right, they are both cheap and easy so they were kept. The goal with the
> nomerges switch was to save CPU, so it'll still do cheap merges. I don't
> think there's a use for disabling merges completely outside of device
> testing and benchmarking, it's not a real world problem. That said, I do
> occasionally hack that up as well for testing purposes. Perhaps we could
> tweak nomerges to accept a '2' value as well, indicating that we don't
> want any merges at all.
> 

John (& Jens) - 

Please find attached a patch that does this - new documentation
for /sys/block/*/queue/nomerges:

+This enables the user to disable the lookup logic involved with IO
+merging requests in the block layer. By default (0) all merges are
+enabled. When set to 1 only simple one-hit merges will be tried. When
+set to 2 no merge algorithms will be tried (including one-hit or more
+complex tree/hash lookups).

John: let me know if this does what you'd think - then I'll go post to
LKML.

Regards,
Alan

[-- Attachment #2: 001-Added-in-stricter-no-merge-semantics-for-block-I-O.patch.txt --]
[-- Type: text/plain, Size: 4505 bytes --]

From 992fc11fd2818e17a70832943fd49dc3130544db Mon Sep 17 00:00:00 2001
From: Alan D. Brunelle <alan.brunelle@hp.com>
Date: Wed, 20 Jan 2010 11:08:05 -0500
Subject: [PATCH] Added in stricter no merge semantics for block I/O

Updated 'nomerges' tunable to accept a value of '2' - indicating that _no_
merges at all are to be attempted (not even the simple one-hit cache).

Signed-off-by: Alan D. Brunelle <alan.brunelle@hp.com>
---
 Documentation/block/queue-sysfs.txt |   10 +++++-----
 block/blk-sysfs.c                   |   11 +++++++----
 block/elevator.c                    |   11 ++++++++++-
 include/linux/blkdev.h              |    3 +++
 4 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/Documentation/block/queue-sysfs.txt b/Documentation/block/queue-sysfs.txt
index e164403..f652740 100644
--- a/Documentation/block/queue-sysfs.txt
+++ b/Documentation/block/queue-sysfs.txt
@@ -25,11 +25,11 @@ size allowed by the hardware.
 
 nomerges (RW)
 -------------
-This enables the user to disable the lookup logic involved with IO merging
-requests in the block layer. Merging may still occur through a direct
-1-hit cache, since that comes for (almost) free. The IO scheduler will not
-waste cycles doing tree/hash lookups for merges if nomerges is 1. Defaults
-to 0, enabling all merges.
+This enables the user to disable the lookup logic involved with IO
+merging requests in the block layer. By default (0) all merges are
+enabled. When set to 1 only simple one-hit merges will be tried. When
+set to 2 no merge algorithms will be tried (including one-hit or more
+complex tree/hash lookups).
 
 nr_requests (RW)
 ----------------
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index 8606c95..e854424 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -189,7 +189,8 @@ static ssize_t queue_nonrot_store(struct request_queue *q, const char *page,
 
 static ssize_t queue_nomerges_show(struct request_queue *q, char *page)
 {
-	return queue_var_show(blk_queue_nomerges(q), page);
+	return queue_var_show((blk_queue_nomerges(q) << 1) |
+			       blk_queue_noxmerges(q), page);
 }
 
 static ssize_t queue_nomerges_store(struct request_queue *q, const char *page,
@@ -199,10 +200,12 @@ static ssize_t queue_nomerges_store(struct request_queue *q, const char *page,
 	ssize_t ret = queue_var_store(&nm, page, count);
 
 	spin_lock_irq(q->queue_lock);
-	if (nm)
+	queue_flag_clear(QUEUE_FLAG_NOMERGES, q);
+	queue_flag_clear(QUEUE_FLAG_NOXMERGES, q);
+	if (nm == 2)
 		queue_flag_set(QUEUE_FLAG_NOMERGES, q);
-	else
-		queue_flag_clear(QUEUE_FLAG_NOMERGES, q);
+	else if (nm)
+		queue_flag_set(QUEUE_FLAG_NOXMERGES, q);
 	spin_unlock_irq(q->queue_lock);
 
 	return ret;
diff --git a/block/elevator.c b/block/elevator.c
index 9ad5ccc..ee3a883 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -474,6 +474,15 @@ int elv_merge(struct request_queue *q, struct request **req, struct bio *bio)
 	int ret;
 
 	/*
+	 * Levels of merges:
+	 * 	nomerges:  No merges at all attempted
+	 * 	noxmerges: Only simple one-hit cache try
+	 * 	merges:	   All merge tries attempted
+	 */
+	if (blk_queue_nomerges(q))
+		return ELEVATOR_NO_MERGE;
+
+	/*
 	 * First try one-hit cache.
 	 */
 	if (q->last_merge) {
@@ -484,7 +493,7 @@ int elv_merge(struct request_queue *q, struct request **req, struct bio *bio)
 		}
 	}
 
-	if (blk_queue_nomerges(q))
+	if (blk_queue_noxmerges(q))
 		return ELEVATOR_NO_MERGE;
 
 	/*
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index ffb13ad..f71f5c5 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -463,6 +463,7 @@ struct request_queue
 #define QUEUE_FLAG_IO_STAT     15	/* do IO stats */
 #define QUEUE_FLAG_CQ	       16	/* hardware does queuing */
 #define QUEUE_FLAG_DISCARD     17	/* supports DISCARD */
+#define QUEUE_FLAG_NOXMERGES   18	/* No extended merges */
 
 #define QUEUE_FLAG_DEFAULT	((1 << QUEUE_FLAG_IO_STAT) |		\
 				 (1 << QUEUE_FLAG_CLUSTER) |		\
@@ -589,6 +590,8 @@ enum {
 #define blk_queue_queuing(q)	test_bit(QUEUE_FLAG_CQ, &(q)->queue_flags)
 #define blk_queue_stopped(q)	test_bit(QUEUE_FLAG_STOPPED, &(q)->queue_flags)
 #define blk_queue_nomerges(q)	test_bit(QUEUE_FLAG_NOMERGES, &(q)->queue_flags)
+#define blk_queue_noxmerges(q)	\
+	test_bit(QUEUE_FLAG_NOXMERGES, &(q)->queue_flags)
 #define blk_queue_nonrot(q)	test_bit(QUEUE_FLAG_NONROT, &(q)->queue_flags)
 #define blk_queue_io_stat(q)	test_bit(QUEUE_FLAG_IO_STAT, &(q)->queue_flags)
 #define blk_queue_flushing(q)	((q)->ordseq)
-- 
1.6.5

Re: io scheduler merges control

[john smith]

Alan,

Your patch worked, didn't see any other problems, thanks.

If you get a chance, I'd like to understand why/how the block device driver speed influences the number of merges,

thanks,
John

--- On Wed, 1/20/10, Alan D. Brunelle <Alan.Brunelle@hp.com> wrote:

> From: Alan D. Brunelle <Alan.Brunelle@hp.com>
> Subject: Re: io scheduler merges control
> To: "Jens Axboe" <jens.axboe@oracle.com>
> Cc: "john smith" <whalajam@yahoo.com>, fio@vger.kernel.org
> Date: Wednesday, January 20, 2010, 8:18 AM
> On Mon, 2010-01-11 at 14:54 +0100,
> Jens Axboe wrote:
> > On Tue, Jan 05 2010, Alan D. Brunelle wrote:
> > > On Mon, 2010-01-04 at 17:53 -0800, john smith
> wrote:
> > > > Alan,
> > > > 
> > > > I've tried 'echo "1">
> /sys/block/<dsf>/queue/nomerges' but
> > > > fio/sequential-reads merges still occur and
> apparently they are only
> > > > the simple ones that can't be disabled.
> > > > 
> > > > 1) What can I change in the kernel to
> disable ALL the merges
> > > > (including the simple ones)?
> > > > (I tried setting
> iosched_cfq.ops.elevator_merge_fn,
> > > > elevator_merged_fn, elevator_merge_req_fn,
> elevator_allow_merge_fn = 0
> > > > but still fio reported merges)
> > > 
> > > Unfortunately, the "simple" ones were left in
> precisely because they
> > > were (a) easy to do, and (b) were expected to
> happen often enough to
> > > keep them in. Jens may be able to comment
> further.
> > 
> > Right, they are both cheap and easy so they were kept.
> The goal with the
> > nomerges switch was to save CPU, so it'll still do
> cheap merges. I don't
> > think there's a use for disabling merges completely
> outside of device
> > testing and benchmarking, it's not a real world
> problem. That said, I do
> > occasionally hack that up as well for testing
> purposes. Perhaps we could
> > tweak nomerges to accept a '2' value as well,
> indicating that we don't
> > want any merges at all.
> > 
> 
> John (& Jens) - 
> 
> Please find attached a patch that does this - new
> documentation
> for /sys/block/*/queue/nomerges:
> 
> +This enables the user to disable the lookup logic involved
> with IO
> +merging requests in the block layer. By default (0) all
> merges are
> +enabled. When set to 1 only simple one-hit merges will be
> tried. When
> +set to 2 no merge algorithms will be tried (including
> one-hit or more
> +complex tree/hash lookups).
> 
> John: let me know if this does what you'd think - then I'll
> go post to
> LKML.
> 
> Regards,
> Alan
> 


      

Re: io scheduler merges control

[Gurudas Pai]

> 3) The third question is why the number of fio reported "merge"(s) is greater than the number of the "ios"?
These merges are since disk is online. not during the current fio run. 
Restart the machine/disk and run fio test , then fio should report 
accurate merge stats.

Thanks,
-Guru

> 
> --- On Mon, 1/4/10, Alan D. Brunelle <Alan.Brunelle@hp.com> wrote:
> 
>> From: Alan D. Brunelle <Alan.Brunelle@hp.com>
>> Subject: Re: io scheduler merges control
>> To: "john smith" <whalajam@yahoo.com>
>> Cc: fio@vger.kernel.org
>> Date: Monday, January 4, 2010, 6:34 AM
>> On Thu, 2009-12-24 at 11:12 -0800,
> 
>> john smith wrote:
>>> IOPS-reported numbers for a test vary (more than 30%
>> in my case) from one run to another depending on kernel io
>> scheduler merges (reported in "Disk
>> stats/merges=reads/writes") making it hard to
>> measure/compare performance of block drivers, for instance.
>>> I don't see any way to turn off kernel io scheduler
>> merges (cfq or others)
>>> and I'd ask if you would consider adding support for
>> it, disabling the merges per individual device, using sys-fs
>> maybe?
>>> If you do, adding an option to fio for controlling the
>> merges would be useful too,
>>> thanks,
>>> John
>> Hi John - 
>>
>> FYI: there is /sys/block/*/queue/nomerges - when set to one
>> ('echo 1
>>> /sys/block/<dsf>/queue/nomerges) - a lot of the
>> merging attempts are
>> not performed. [Note, _some_ simple merge attempts _are_
>> still attempted
>> regardless of its setting...]
>>
>> Regards,
>> Alan
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> fio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> 
>       
> --
> To unsubscribe from this list: send the line "unsubscribe fio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: io scheduler merges control

[Jens Axboe]

On Mon, Jan 11 2010, Gurudas Pai wrote:
>
>> 3) The third question is why the number of fio reported "merge"(s) is greater than the number of the "ios"?
> These merges are since disk is online. not during the current fio run.  
> Restart the machine/disk and run fio test , then fio should report  
> accurate merge stats.

That's not correct, it is the number of merges that occured while fio
was running. What Alan said is correct, the ios count is the issued
number of ios. Merges can easily be much larger, for this case of small
bs sequential IO it will indeed be pretty huge.

-- 
Jens Axboe

Re: io scheduler merges control

[Chris Worley]

On Thu, Dec 24, 2009 at 12:12 PM, john smith <whalajam@yahoo.com> wrote:
> IOPS-reported numbers for a test vary (more than 30% in my case) from one run to another depending on kernel io scheduler merges (reported in "Disk stats/merges=reads/writes") making it hard to measure/compare performance of block drivers, for instance.

Are you trying to measure sequential I/O?  Most application traces
I've seen show that despite the sequential/random mix reported, the
vast majority of "sequential" accesses are two blocks.  Of course this
isn't true for applications that only do logging and a few others...
but, it means that for most applications, there really isn't any
sequential access to worry about.

Are you disabling the VM Cache w/ Direct I/O?

Maybe tell us more about what you're trying to test.  It may be more a
matter of control and preconditioning than a fio issue.

Chris
>
> I don't see any way to turn off kernel io scheduler merges (cfq or others)
> and I'd ask if you would consider adding support for it, disabling the merges per individual device, using sys-fs maybe?
>
> If you do, adding an option to fio for controlling the merges would be useful too,
>
> thanks,
> John
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe fio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at �http://vger.kernel.org/majordomo-info.html
>

Re: io scheduler merges control

[john smith]

Chris,

see bellow my answers

--- On Mon, 1/4/10, Chris Worley <worleys@gmail.com> wrote:

> From: Chris Worley <worleys@gmail.com>
> Subject: Re: io scheduler merges control
> To: "john smith" <whalajam@yahoo.com>
> Cc: fio@vger.kernel.org
> Date: Monday, January 4, 2010, 6:52 AM
> On Thu, Dec 24, 2009 at 12:12 PM,
> john smith <whalajam@yahoo.com>
> wrote:
> > IOPS-reported numbers for a test vary (more than 30%
> in my case) from one run to another depending on kernel io
> scheduler merges (reported in "Disk
> stats/merges=reads/writes") making it hard to
> measure/compare performance of block drivers, for instance.
> 
> Are you trying to measure sequential I/O?� Most
> application traces
> I've seen show that despite the sequential/random mix
> reported, the
> vast majority of "sequential" accesses are two
> blocks.� Of course this
> isn't true for applications that only do logging and a few
> others...
> but, it means that for most applications, there really
> isn't any
> sequential access to worry about.

I'm doing 512B sequential reads.
 
> Are you disabling the VM Cache w/ Direct I/O?

Yes.
 
> Maybe tell us more about what you're trying to test.�
> It may be more a
> matter of control and preconditioning than a fio issue.

I'm trying to compare two block drivers, when running "fio" I get from the first driver larger "iops" number but also larger "merges" number; the other driver has lower "iops" and no merges.
Not sure why one driver has merges and the other doesn't but I'm trying to prevent merges (on both) in order to compare the drivers performance.

John
 
> Chris
> >
> > I don't see any way to turn off kernel io scheduler
> merges (cfq or others)
> > and I'd ask if you would consider adding support for
> it, disabling the merges per individual device, using sys-fs
> maybe?
> >
> > If you do, adding an option to fio for controlling the
> merges would be useful too,
> >
> > thanks,
> > John
> >
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line
> "unsubscribe fio" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at �http://vger.kernel.org/majordomo-info.html
> >
> --
> To unsubscribe from this list: send the line "unsubscribe
> fio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at� http://vger.kernel.org/majordomo-info.html
>