blk-mq merge flags

Christoph Hellwig hch at lst.de
Thu Mar 3 03:59:53 PST 2016


On Thu, Mar 03, 2016 at 07:24:10PM +0800, Ming Lei wrote:
> After bio splitting is introduced, SG merging becomes much cheaper, and
> I can't see the difference between SG_MERGE and NO_SG_MERGE when
> doing test over null_blk.

Ok.

> Once multipage bvecs is supported, SG merging should be always because
> the bvec stored in bio->bi_io_vec can be thought as sort of segment.
> 
> Also from hardware view, it is often more efficient to handle less segments.
> Last time Keith mentioned the point too about NVMe.
> 
> That is why I think we might consider to remove the flag.

I hate these sorts of flags, but we have to weight this against the
reason they were introduced.  I think the rational was for workloads
that do small (4k or less) I/Os and really care about latency.

But I'd be much happier if we'd only allow this to be turned off at
runtime through sysfs, and not requiring the drivers to opt for
sane behavior at compile time.

I also agree about the multipage biovecs - if we build large iovecs
directly in bio_add_page we get S/G merging for a two comparisms and
a branch, so it'll be essentially for free.  But for that we need
multipage biovecs first.



More information about the Linux-nvme mailing list