On Thu, Mar 3, 2016 at 4:46 PM, Christoph Hellwig <hch@xxxxxx> wrote: > On Thu, Mar 03, 2016 at 07:55:15AM +0800, Ming Lei wrote: >> > command indeed. Except for keeping the flags in sync, which sounds >> > like a good іdea in general there is not reall need for this one. >> >> NO_SG_MERGE has been bypassed after bio splitting is introduced, >> and looks it should have been removed. > > Partially at least. Anyway, let's start a discussion on blk-mq merge > flags. > > First I really hate the way how any merges are opt-in. I'd be much > happier with an opt-out to get the sane behavior by default. Every > drivers set BLK_MQ_F_SHOULD_MERGE, and while only a few drivers set > BLK_MQ_F_SG_MERGE I suspect all should as well. Especially as the > SG merging is cheaper and more useful than the bio mergig in many > cases. 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. 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. -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
