From patchwork Sat Oct 29 08:08:27 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 9403401 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 72E6260587 for ; Sat, 29 Oct 2016 08:28:45 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5F07B2A1EA for ; Sat, 29 Oct 2016 08:28:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 52B652A63F; Sat, 29 Oct 2016 08:28:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0D5F22A1EA for ; Sat, 29 Oct 2016 08:28:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935206AbcJ2I2Y (ORCPT ); Sat, 29 Oct 2016 04:28:24 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:34991 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756978AbcJ2IOE (ORCPT ); Sat, 29 Oct 2016 04:14:04 -0400 Received: by mail-pf0-f193.google.com with SMTP id s8so3381206pfj.2; Sat, 29 Oct 2016 01:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=3gcwGy4xTkaY+7Xy2sglK9nT22mWOeyPMFi5SaYUzHE=; b=bVnv/iVVqE8b60cWwCOKD9kyVwngGNsk2HbI6uO9iSnaJ/YtQhCo8KzwpzyUf43KCx FEMJDdsvFy+cJtZ0YmUB/DYhIUl6gCV9uSbMzVF3exQjG8/gY8TEBrls5QuInwFhXj8d 2DTvKdyPUhsaT/z4Njm+9gN4pnlLlqsMY9lzQWt87HnUR8Nz9VaTQrDIVPcjhUPDPMMY 6PMSuFduJOr+Oodvm64GmeK2gH63v12CVCR58nu6lH8pqcXahOnW2CSnCdbGGZFvGXxN NOXGhji1oNIoCYa4qubB6I64lAbT7xoQSEuip9wR8yWfT55yCaUsk1OxdHqCYtPfRm6V txkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=3gcwGy4xTkaY+7Xy2sglK9nT22mWOeyPMFi5SaYUzHE=; b=GGmRoH2nBcZS8pKhxHJ5vpQhMBtYe9TO1C0o8RWY/ebAPD1xNNO2jWlyteq33jvS3Z 3Cs8ekag2UXPrjVyv0+u2mk5VOcE0Dgr8BGUvl7bfZK1Op+1VlTrLKiCokv4xPIpYQlM JYdfZII+CndyOXwkNgHU3s+UT2ysoZumKxOy1mSAF/hho8Z8Ca+qLp4phZSJMXe3r3G5 J+1EdOAY3F6zewDK4OhmpdQ8avKMCH410o2WfrFg8Jx49agg6WyTTTMTtECmUJmgRCt3 7pRO1aQraiwOrD6Dt2fclJS6QXtF9q/ZKu1ZnMasUcFhysVwTvKdDyEMIq9PlEyIyDBp Gf8A== X-Gm-Message-State: ABUngvf2uZEYEHguYWMMBmLDwGG04F+ZKcFhakz5LZog6gdpHqaERtrx7AoIlUnakY0Ytw== X-Received: by 10.98.69.151 with SMTP id n23mr31600329pfi.60.1477728843741; Sat, 29 Oct 2016 01:14:03 -0700 (PDT) Received: from localhost ([45.34.23.101]) by smtp.gmail.com with ESMTPSA id r1sm19342165pfg.56.2016.10.29.01.14.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Oct 2016 01:14:03 -0700 (PDT) From: Ming Lei To: Jens Axboe , linux-kernel@vger.kernel.org Cc: linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Christoph Hellwig , "Kirill A . Shutemov" , Ming Lei , Jens Axboe , Hannes Reinecke , Mike Christie , Dan Williams , Toshi Kani Subject: [PATCH 28/60] block: introduce QUEUE_FLAG_SPLIT_MP Date: Sat, 29 Oct 2016 16:08:27 +0800 Message-Id: <1477728600-12938-29-git-send-email-tom.leiming@gmail.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1477728600-12938-1-git-send-email-tom.leiming@gmail.com> References: <1477728600-12938-1-git-send-email-tom.leiming@gmail.com> Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Some drivers(such as dm) should be capable of dealing with multipage bvec, but the incoming bio may be too big, such as, a new singlepage bvec bio can't be cloned from the bio, or can't be allocated to singlepage bvec with same size. At least crypt dm, log writes and bcache have this kind of issue. Signed-off-by: Ming Lei --- block/blk-merge.c | 4 ++++ include/linux/blkdev.h | 2 ++ 2 files changed, 6 insertions(+) diff --git a/block/blk-merge.c b/block/blk-merge.c index 2642e5fc8b69..266c94d1d82f 100644 --- a/block/blk-merge.c +++ b/block/blk-merge.c @@ -79,6 +79,10 @@ static inline unsigned get_max_io_size(struct request_queue *q, /* aligned to logical block size */ sectors &= ~(mask >> 9); + /* some queues can't handle bigger bio even it is ready for mp bvecs */ + if (blk_queue_split_mp(q) && sectors > BIO_SP_MAX_SECTORS) + sectors = BIO_SP_MAX_SECTORS; + return sectors; } diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index e4dd25361bd6..7cee0179c9e6 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -506,6 +506,7 @@ struct request_queue { #define QUEUE_FLAG_FLUSH_NQ 25 /* flush not queueuable */ #define QUEUE_FLAG_DAX 26 /* device supports DAX */ #define QUEUE_FLAG_NO_MP 27 /* multipage bvecs isn't ready */ +#define QUEUE_FLAG_SPLIT_MP 28 /* split MP bvecs if too bigger */ #define QUEUE_FLAG_DEFAULT ((1 << QUEUE_FLAG_IO_STAT) | \ (1 << QUEUE_FLAG_STACKABLE) | \ @@ -597,6 +598,7 @@ static inline void queue_flag_clear(unsigned int flag, struct request_queue *q) (test_bit(QUEUE_FLAG_SECERASE, &(q)->queue_flags)) #define blk_queue_dax(q) test_bit(QUEUE_FLAG_DAX, &(q)->queue_flags) #define blk_queue_no_mp(q) test_bit(QUEUE_FLAG_NO_MP, &(q)->queue_flags) +#define blk_queue_split_mp(q) test_bit(QUEUE_FLAG_SPLIT_MP, &(q)->queue_flags) #define blk_noretry_request(rq) \ ((rq)->cmd_flags & (REQ_FAILFAST_DEV|REQ_FAILFAST_TRANSPORT| \