Re: dm-mpath request merging concerns [was: Re: It's time to put together the schedule]

[Mike Snitzer <snitzer@redhat.com>]

On Tue, Feb 24 2015 at  9:35am -0500,
Jeff Moyer <jmoyer@redhat.com> wrote:

> Mike Snitzer <snitzer@redhat.com> writes:
> 
> > Jens and/or Jeff Moyer, are there any knobs that you'd suggest to try to
> > promote request merging on a really fast block device?  Any scheduler
> > and knobs you'd suggest would be appreciated.
> 
> There's a small chance that CFQ does what you want.  It has logic to
> detect when multiple processes are submitting interleaved I/O, and it
> will try to wait until requests are merged before dispatching (see
> the comment in cfq_rq_enqueued).

That comment wasn't overly insightful on CFQ's ability to wait for
merging when IO is being submitted larger than a page size to begin
with.  Why will it "immediately let it rip" if the request is only just
larger than a single page?  Seems we'd like that threshold to be higher
depending on the workload (would it be wrong to make it tunable?).
Maybe it is a perfectly fine heuristic as is and I'm just missing it?

FYI, CFQ didn't work any better for NetApp when they tested it last
night; but they likely didn't set rotational.

> Aside from that, make sure /sys/block/<dev>/queue/rotational is set to 1.

Fair point (albeit unintuitive to the user who has an SSD backend).

I'll see if NetApp can re-test CFQ with rotational set.