Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1957807imu; Fri, 23 Nov 2018 02:42:14 -0800 (PST) X-Google-Smtp-Source: AFSGD/W3Ohf1iiNlLOM3SZiiMdTpshu4XwNjUaLF/5wQqw/myEoSk6SAukkwe1FKV4/6dldamKEi X-Received: by 2002:a63:dc54:: with SMTP id f20mr13695858pgj.410.1542969734894; Fri, 23 Nov 2018 02:42:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542969734; cv=none; d=google.com; s=arc-20160816; b=nAz1rO3vscpuWo9Rm+J/2Nc/8GQ2PcvEURw7+cm7Flj+v0xhhPouUbzquZixIHk+oK VtuGFzLi7/iEBt6PyiVKve69FhSyFQwo7fRZyk43NL9sksE3N4LQyFzZ6+x6HcZhyiac SJxT9F2+9P45Qtl4mZuJFZvecLFidVKGtldRrnzxsd4Gu899/tpEoFXzRYLQ2r9a+sJu 7oH1NknODq0jSEf/ju0N5FHbtl9Pso+AYI6YklM+76kZhiGj51u5GjELgbfiBhh5+kCh nCGuuvvErWJmQwNqbHLjX7HyzScE729O8rBFMoXrgI5zOT7qXq+4ln37vvyK1LRtdkJk M6qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=A51BFP6ptJ+5geKSSvXw9SMDEHr7CFk6KJtZew/epkU=; b=g4kxj8bW4nf7lddyXVi/f7b+D45f+vrDLjMvSROaPDnz2uDlgf4R4dKCaJCIbZy7TT K/JWG9yVecUQSRFJ0TlVqOPm+3pW6HjROSk6vl1far3YoqxtLYyx1pJd6SupTJx9qiyA eHyK6vf7yxU2vr+C3QEgnbiOJfVQSRrLwrAIqBnhHP3Q6KV2eBegd6RP4vDw9k0LvyJ+ 3WQGd3koKch3FdG+hx8uNSx4DKQaKRpchV1GGNB6j4QwNnvv8Z7MmfDtG5UV/r2h3Mdc UcLrg8FakOllCwMGpEAJpx75psyWWfVa0j8ML/2Y6BHncDpajnNWk8h/EYxJqqUmQahk iQKg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u27si7505419pfa.103.2018.11.23.02.42.00; Fri, 23 Nov 2018 02:42:14 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394179AbeKVVB7 (ORCPT + 99 others); Thu, 22 Nov 2018 16:01:59 -0500 Received: from verein.lst.de ([213.95.11.211]:57417 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387625AbeKVVB7 (ORCPT ); Thu, 22 Nov 2018 16:01:59 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 286AA68BC7; Thu, 22 Nov 2018 11:23:09 +0100 (CET) Date: Thu, 22 Nov 2018 11:23:09 +0100 From: Christoph Hellwig To: Ming Lei Cc: Christoph Hellwig , Jens Axboe , 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 , linux-ext4@vger.kernel.org, Coly Li , linux-bcache@vger.kernel.org, Boaz Harrosh , Bob Peterson , cluster-devel@redhat.com Subject: Re: [PATCH V11 03/19] block: introduce bio_for_each_bvec() Message-ID: <20181122102309.GA29295@lst.de> References: <20181121032327.8434-1-ming.lei@redhat.com> <20181121032327.8434-4-ming.lei@redhat.com> <20181121133244.GB1640@lst.de> <20181121153135.GB19111@ming.t460p> <20181121161025.GB4977@lst.de> <20181121171217.GA6259@lst.de> <20181122101527.GB27273@ming.t460p> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181122101527.GB27273@ming.t460p> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 22, 2018 at 06:15:28PM +0800, Ming Lei wrote: > > while (bytes) { > > - unsigned segment_len = segment_iter_len(bv, *iter); > > - > > - if (max_seg_len < BVEC_MAX_LEN) > > - segment_len = min_t(unsigned, segment_len, > > - max_seg_len - > > - bvec_iter_offset(bv, *iter)); > > + unsigned iter_len = bvec_iter_len(bv, *iter); > > + unsigned len = min(bytes, iter_len); > > It may not work to always use bvec_iter_len() here, and 'segment_len' > should be max length of the passed 'bv', however we don't know if it is > single-page or mutli-page bvec if no one tells us. The plain revert I sent isn't totally correct in your current tree indeed because of the odd change that segment_iter_len now is the full bvec len, so it should be changed to that until we switch to the sane naming scheme used elsewhere. But except for that, it will work. The bvec we operate on (part of the array in the bio pointed to by the iter) is always a multi-page capable one. We only fake up a single page on for users using segment_iter_len. Think of what you are doing in the (I think mostly hypothetical) case that we call bvec_iter_advance with a bytes > PAGE_SIZE on a segment small than page size. In this case we will limit the current iteration to the while loop until we git a page boundary. This means we will not hit the condition moving to the next (real, in the array) bvec at the end of the loop, and just go on into the next iteration of the loop with the reduced amount of bytes. Depending on how large byte is this might repeat a few more times. Then on the final one we hit the limit and move to the next (real, in the array) bvec. Now if we don't have the segment limit we do exactly the same thing, just a whole lot more efficiently in a single loop iteration. tree where segment_iter_len is the