From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752586AbcBOU1R (ORCPT ); Mon, 15 Feb 2016 15:27:17 -0500 Received: from mail-wm0-f46.google.com ([74.125.82.46]:37984 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752413AbcBOU1N (ORCPT ); Mon, 15 Feb 2016 15:27:13 -0500 Subject: Re: [PATCH 2/4] block: check virt boundary in bio_will_gap() To: Ming Lei References: <1455519687-23873-1-git-send-email-ming.lei@canonical.com> <1455519687-23873-3-git-send-email-ming.lei@canonical.com> <56C18AE1.9020201@dev.mellanox.co.il> Cc: Jens Axboe , Linux Kernel Mailing List , linux-block@vger.kernel.org, Christoph Hellwig From: Sagi Grimberg Message-ID: <56C2349D.4020708@dev.mellanox.co.il> Date: Mon, 15 Feb 2016 22:27:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h >>> index 4571ef1..b8ff6a3 100644 >>> --- a/include/linux/blkdev.h >>> +++ b/include/linux/blkdev.h >>> @@ -1388,7 +1388,7 @@ static inline bool bvec_gap_to_prev(struct >>> request_queue *q, >>> static inline bool bio_will_gap(struct request_queue *q, struct bio >>> *prev, >>> struct bio *next) >>> { >>> - if (!bio_has_data(prev)) >>> + if (!bio_has_data(prev) || !queue_virt_boundary(q)) >>> bio_integrity_add_page return false; >> >> >> Can we not do that? > > Given there are only 3 drivers which set virt boundary, I think > it is reasonable to do that. 3 drivers that are really performance critical. I don't think we should add optimized branching for some of the drivers especially when the drivers that do set virt_boundary *really* care about latency. >> bvec_gap_to_prev is already checking the virt_boundary and I'd sorta >> like to keep the motivation to optimize bio_get_last_bvec() to be O(1). > > Currently the approaches I thought of still need to iterate bvec by bvec, > not sure if O(1) can be reached easily, but I am happy to discuss the > optimized implementation. Me too. Note that I don't mind if the bio split code won't be optimized, but I do want req_gap_back_merge/req_gap_front_merge to be... Also, are the bvec_gap_to_prev usages in bio_add_pc_page and bio_integrity_add_page safe? I didn't test this stuff with integrity payloads...