[dm-devel] dm-mpath request merging concerns [was: Re: It's time to put together the schedule]
Mike Snitzer
snitzer at redhat.com
Tue Feb 24 14:59:41 UTC 2015
On Tue, Feb 24 2015 at 9:35am -0500,
Jeff Moyer <jmoyer at redhat.com> wrote:
> Mike Snitzer <snitzer at 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.
More information about the dm-devel
mailing list