On Tue, Feb 24 2015 at 9:35am -0500, Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: > Mike Snitzer <snitzer@xxxxxxxxxx> 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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
