From patchwork Wed Nov 21 03:23:08 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 10691585 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id EACDC13BB for ; Wed, 21 Nov 2018 03:24:49 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CC1F72B406 for ; Wed, 21 Nov 2018 03:24:49 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BC9DC2B409; Wed, 21 Nov 2018 03:24:49 +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=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D2BBA2B406 for ; Wed, 21 Nov 2018 03:24:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 93CA66B2390; Tue, 20 Nov 2018 22:24:47 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 8C5266B2391; Tue, 20 Nov 2018 22:24:47 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 78DEB6B2392; Tue, 20 Nov 2018 22:24:47 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by kanga.kvack.org (Postfix) with ESMTP id 4CCCB6B2390 for ; Tue, 20 Nov 2018 22:24:47 -0500 (EST) Received: by mail-qk1-f198.google.com with SMTP id 92so5463249qkx.19 for ; Tue, 20 Nov 2018 19:24:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:message-id; bh=1OSjh3ojyfRzNQ0S4ZqrnGQq07/L82zHBEtNunByzEY=; b=SClIejbUpSLUYikJJrt9bumSOpjr+4g4A02BXlmfWW+3BQQT8n9t3Q30l8cE+8DIRi 2SPf87Gh5EFejahTi3FMdAuHkVPQ7iTRoF6ko5hiAuKY1TOXqhX7m1TXaAC6/g+GIbn9 Vm7CfJPFPU1gy1VKXpqSqUTFGonUeCYx7Y0axhPrBEJlG1lQC4M87acLDKG2x12Tg828 mRetNnDiyeK5/52OmGYn7X/c5oszqxWpmDgSZScEVFQ8hs9BsznUL3ZdreT7UFP27Z3L jOllEqLm+hffviVPzi5lyyvDJ861O6+Zfyanrr43Bgbjgxqyv39ayOV8K9G2alZSSc3x QFPg== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ming.lei@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=ming.lei@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com X-Gm-Message-State: AGRZ1gIfLfliWbsMnzCmju/mwFSTVj2ecqV4chNjPjW3/OgOZG45H94P rXpOgFKrEqjXqOqHkfv4WKQe8ODvjIohGiLmwzBAbgp52TltbepotqftXWmwvgUWkJtlBrc+45e uHUUSfjxjeLuK68PzR8B+gLv/8xwdfyVy4o0NncOSjqSwfhk0SR1aop25N7LbDWDNEg== X-Received: by 2002:ac8:3971:: with SMTP id t46mr4245706qtb.331.1542770687027; Tue, 20 Nov 2018 19:24:47 -0800 (PST) X-Google-Smtp-Source: AJdET5czsOWHPZmmAM2/IqlHfbcsgqMZogmzynS+EmCv5W7GpL87t5eYC1AC83+U53lgUnx943fg X-Received: by 2002:ac8:3971:: with SMTP id t46mr4245669qtb.331.1542770685833; Tue, 20 Nov 2018 19:24:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542770685; cv=none; d=google.com; s=arc-20160816; b=07y2+CwsMx+PbUZRXJPzFnywuPekheLhMA7dUN3Jtgb3NKfiZX3Ud1IHF2KpXrgZT0 7X0WJFZemZkQZZpMm0cnyiMbhEOwdXvJ5GziV0Nmf+9tlmZJSsI4+6peGnsWyQZnFLO6 ehLmj2WvVWdmtuPaiwUtZrVviNNA2pNNyBlU5XiDCr69S8glZk1xRpL20L0im4+GvnAT 4/YW7a2fnuyixyIcIGzTrR8vnIBz7PbmxsnJwXDNvGkF8PFuI/5/owQD9p2DC1OHFGcw GP8Glae6fQMKV0YWNQ9ZaDEtaY5VhweAkJweoO/JmvwFylWGFzgt8owrhw3I3c6fKrhK 5O4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:subject:cc:to:from; bh=1OSjh3ojyfRzNQ0S4ZqrnGQq07/L82zHBEtNunByzEY=; b=Fv4yWJVM28rYvwczg3O0kEBsuycLOlnWm1HBHDyOAHLiEIWw4kQ7QDzAwGwetfTn9S 9GGOTHOxsi6HTYM+r25+nySh7JSSwdmVkC5OFXm0RVIh+8ndtQbviRfwmndvVqgStAWX cCdu285iVzNaqfAC4wNRTPjKNMc+eUCcC5vV5XmLZbyYrZOXCZCkL6oY1a84sDqF1cuU xI2mmlTrm/aoNgyTJnvSoIqu5MNkQHlTNy/bWGiqBBVKMwrOwHoovEeIPhi+JXfEqMTM t0UKgoCW2F3DzYnVZ6ThGjtfJdXAVByBcdPuKN+z07shCRs4LEp9J7Rp5DOaVzHrWLMu qkkQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of ming.lei@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=ming.lei@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id s33si1290083qts.306.2018.11.20.19.24.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 19:24:45 -0800 (PST) Received-SPF: pass (google.com: domain of ming.lei@redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; Authentication-Results: mx.google.com; spf=pass (google.com: domain of ming.lei@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=ming.lei@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 65502811D6; Wed, 21 Nov 2018 03:24:44 +0000 (UTC) Received: from localhost (ovpn-8-21.pek2.redhat.com [10.72.8.21]) by smtp.corp.redhat.com (Postfix) with ESMTP id F34BA19C7F; Wed, 21 Nov 2018 03:24:31 +0000 (UTC) From: Ming Lei To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Theodore Ts'o , Omar Sandoval , Sagi Grimberg , Dave Chinner , Kent Overstreet , Mike Snitzer , dm-devel@redhat.com, Alexander Viro , linux-fsdevel@vger.kernel.org, Shaohua Li , linux-raid@vger.kernel.org, David Sterba , linux-btrfs@vger.kernel.org, "Darrick J . Wong" , linux-xfs@vger.kernel.org, Gao Xiang , Christoph Hellwig , linux-ext4@vger.kernel.org, Coly Li , linux-bcache@vger.kernel.org, Boaz Harrosh , Bob Peterson , cluster-devel@redhat.com, Ming Lei Subject: [PATCH V11 00/19] block: support multi-page bvec Date: Wed, 21 Nov 2018 11:23:08 +0800 Message-Id: <20181121032327.8434-1-ming.lei@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 21 Nov 2018 03:24:45 +0000 (UTC) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: X-Virus-Scanned: ClamAV using ClamSMTP Hi, This patchset brings multi-page bvec into block layer: 1) what is multi-page bvec? Multipage bvecs means that one 'struct bio_bvec' can hold multiple pages which are physically contiguous instead of one single page used in linux kernel for long time. 2) why is multi-page bvec introduced? Kent proposed the idea[1] first. As system's RAM becomes much bigger than before, and huge page, transparent huge page and memory compaction are widely used, it is a bit easy now to see physically contiguous pages from fs in I/O. On the other hand, from block layer's view, it isn't necessary to store intermediate pages into bvec, and it is enough to just store the physicallly contiguous 'segment' in each io vector. Also huge pages are being brought to filesystem and swap [2][6], we can do IO on a hugepage each time[3], which requires that one bio can transfer at least one huge page one time. Turns out it isn't flexiable to change BIO_MAX_PAGES simply[3][5]. Multipage bvec can fit in this case very well. As we saw, if CONFIG_THP_SWAP is enabled, BIO_MAX_PAGES can be configured as much bigger, such as 512, which requires at least two 4K pages for holding the bvec table. With multi-page bvec: - Inside block layer, both bio splitting and sg map can become more efficient than before by just traversing the physically contiguous 'segment' instead of each page. - segment handling in block layer can be improved much in future since it should be quite easy to convert multipage bvec into segment easily. For example, we might just store segment in each bvec directly in future. - bio size can be increased and it should improve some high-bandwidth IO case in theory[4]. - there is opportunity in future to improve memory footprint of bvecs. 3) how is multi-page bvec implemented in this patchset? Patch 1 fixes one issue of misusing on bio->bi_vcnt. Patches 2 ~ 15 implement multipage bvec in block layer: - put all tricks into bvec/bio/rq iterators, and as far as drivers and fs use these standard iterators, they are happy with multipage bvec - introduce bio_for_each_bvec() to iterate over multipage bvec for splitting bio and mapping sg - keep current bio_for_each_segment*() to itereate over singlepage bvec and make sure current users won't be broken; especailly, convert to this new helper prototype in single patch 21 given it is bascially a mechanism conversion - deal with iomap & xfs's sub-pagesize io vec in patch 13 - enalbe multipage bvec in patch 14 Patch 16 redefines BIO_MAX_PAGES as 256. Patch 17 documents usages of bio iterator helpers. Patch 18~19 kills NO_SG_MERGE. These patches can be found in the following git tree: git: https://github.com/ming1/linux.git for-4.21-block-mp-bvec-V11 Lots of test(blktest, xfstests, ltp io, ...) have been run with this patchset, and not see regression. Thanks Christoph for reviewing the early version and providing very good suggestions, such as: introduce bio_init_with_vec_table(), remove another unnecessary helpers for cleanup and so on. Thanks Chritoph and Omar for reviewing V10, and provides lots of helpful comments. Any comments are welcome! V11: - address most of reviews from Omar and christoph - rename mp_bvec_* as segment_* helpers - remove 'mp' parameter from bvec_iter_advance() and related helpers - cleanup patch on bvec_split_segs() and blk_bio_segment_split(), remove unnecessary checks - simplify bvec_last_segment() - drop bio_pages_all() - introduce dedicated functions/file for handling non-cluser bio for avoiding checking queue cluster before adding page to bio - introduce bio_try_merge_segment() for simplifying iomap/xfs page accounting code - Fix Document change V10: - no any code change, just add more guys and list into patch's CC list, as suggested by Christoph and Dave Chinner V9: - fix regression on iomap's sub-pagesize io vec, covered by patch 13 V8: - remove prepare patches which all are merged to linus tree - rebase on for-4.21/block - address comments on V7 - add patches of killing NO_SG_MERGE V7: - include Christoph and Mike's bio_clone_bioset() patches, which is actually prepare patches for multipage bvec - address Christoph's comments V6: - avoid to introduce lots of renaming, follow Jen's suggestion of using the name of chunk for multipage io vector - include Christoph's three prepare patches - decrease stack usage for using bio_for_each_chunk_segment_all() - address Kent's comment V5: - remove some of prepare patches, which have been merged already - add bio_clone_seg_bioset() to fix DM's bio clone, which is introduced by 18a25da84354c6b (dm: ensure bio submission follows a depth-first tree walk) - rebase on the latest block for-v4.18 V4: - rename bio_for_each_segment*() as bio_for_each_page*(), rename bio_segments() as bio_pages(), rename rq_for_each_segment() as rq_for_each_pages(), because these helpers never return real segment, and they always return single page bvec - introducing segment_for_each_page_all() - introduce new bio_for_each_segment*()/rq_for_each_segment()/bio_segments() for returning real multipage segment - rewrite segment_last_page() - rename bvec iterator helper as suggested by Christoph - replace comment with applying bio helpers as suggested by Christoph - document usage of bio iterator helpers - redefine BIO_MAX_PAGES as 256 to make the biggest bvec table accommodated in 4K page - move bio_alloc_pages() into bcache as suggested by Christoph V3: - rebase on v4.13-rc3 with for-next of block tree - run more xfstests: xfs/ext4 over NVMe, Sata, DM(linear), MD(raid1), and not see regressions triggered - add Reviewed-by on some btrfs patches - remove two MD patches because both are merged to linus tree already V2: - bvec table direct access in raid has been cleaned, so NO_MP flag is dropped - rebase on recent Neil Brown's change on bio and bounce code - reorganize the patchset V1: - against v4.10-rc1 and some cleanup in V0 are in -linus already - handle queue_virt_boundary() in mp bvec change and make NVMe happy - further BTRFS cleanup - remove QUEUE_FLAG_SPLIT_MP - rename for two new helpers of bio_for_each_segment_all() - fix bounce convertion - address comments in V0 [1], http://marc.info/?l=linux-kernel&m=141680246629547&w=2 [2], https://patchwork.kernel.org/patch/9451523/ [3], http://marc.info/?t=147735447100001&r=1&w=2 [4], http://marc.info/?l=linux-mm&m=147745525801433&w=2 [5], http://marc.info/?t=149569484500007&r=1&w=2 [6], http://marc.info/?t=149820215300004&r=1&w=2 Ming Lei (19): block: don't use bio->bi_vcnt to figure out segment number block: introduce multi-page bvec helpers block: introduce bio_for_each_bvec() block: use bio_for_each_bvec() to compute multi-page bvec count block: use bio_for_each_bvec() to map sg block: introduce bvec_last_segment() fs/buffer.c: use bvec iterator to truncate the bio btrfs: use bvec_last_segment to get bio's last page btrfs: move bio_pages_all() to btrfs block: loop: pass multi-page bvec to iov_iter bcache: avoid to use bio_for_each_segment_all() in bch_bio_alloc_pages() block: allow bio_for_each_segment_all() to iterate over multi-page bvec block: move bounce_clone_bio into bio.c block: handle non-cluster bio out of blk_bio_segment_split block: enable multipage bvecs block: always define BIO_MAX_PAGES as 256 block: document usage of bio iterator helpers block: kill QUEUE_FLAG_NO_SG_MERGE block: kill BLK_MQ_F_SG_MERGE Documentation/block/biovecs.txt | 24 +++++ block/Makefile | 3 +- block/bio.c | 128 +++++++++++++++++++++--- block/blk-merge.c | 198 ++++++++++++++++++++++++-------------- block/blk-mq-debugfs.c | 2 - block/blk-mq.c | 3 - block/blk.h | 4 + block/bounce.c | 76 +-------------- block/non-cluster.c | 70 ++++++++++++++ drivers/block/loop.c | 22 ++--- drivers/block/nbd.c | 2 +- drivers/block/rbd.c | 2 +- drivers/block/skd_main.c | 1 - drivers/block/xen-blkfront.c | 2 +- drivers/md/bcache/btree.c | 3 +- drivers/md/bcache/util.c | 6 +- drivers/md/dm-crypt.c | 3 +- drivers/md/dm-rq.c | 2 +- drivers/md/dm-table.c | 13 --- drivers/md/raid1.c | 3 +- drivers/mmc/core/queue.c | 3 +- drivers/scsi/scsi_lib.c | 2 +- drivers/staging/erofs/data.c | 3 +- drivers/staging/erofs/unzip_vle.c | 3 +- fs/block_dev.c | 6 +- fs/btrfs/compression.c | 3 +- fs/btrfs/disk-io.c | 3 +- fs/btrfs/extent_io.c | 29 ++++-- fs/btrfs/inode.c | 6 +- fs/btrfs/raid56.c | 3 +- fs/buffer.c | 5 +- fs/crypto/bio.c | 3 +- fs/direct-io.c | 4 +- fs/exofs/ore.c | 3 +- fs/exofs/ore_raid.c | 3 +- fs/ext4/page-io.c | 3 +- fs/ext4/readpage.c | 3 +- fs/f2fs/data.c | 9 +- fs/gfs2/lops.c | 6 +- fs/gfs2/meta_io.c | 3 +- fs/iomap.c | 8 +- fs/mpage.c | 3 +- fs/xfs/xfs_aops.c | 7 +- include/linux/bio.h | 50 ++++++---- include/linux/blk-mq.h | 1 - include/linux/blkdev.h | 5 +- include/linux/bvec.h | 115 ++++++++++++++++++++-- 47 files changed, 595 insertions(+), 264 deletions(-) create mode 100644 block/non-cluster.c