Re: io scheduler merges control

["Alan D. Brunelle" <Alan.Brunelle@hp.com>]

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