linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Ming Lei <ming.lei@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org,
	Pavel Begunkov <asml.silence@gmail.com>,
	Christoph Hellwig <hch@infradead.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] block: add bio_iov_iter_nvecs for figuring out nr_vecs
Date: Tue, 1 Dec 2020 12:52:51 +0000	[thread overview]
Message-ID: <20201201125251.GA11935@casper.infradead.org> (raw)
In-Reply-To: <20201201120652.487077-1-ming.lei@redhat.com>

On Tue, Dec 01, 2020 at 08:06:52PM +0800, Ming Lei wrote:
> Pavel reported that iov_iter_npages is a bit heavy in case of bvec
> iter.
> 
> Turns out it isn't necessary to iterate every page in the bvec iter,
> and we call iov_iter_npages() just for figuring out how many bio
> vecs need to be allocated. And we can simply map each vector in bvec iter
> to bio's vec, so just return iter->nr_segs from bio_iov_iter_nvecs() for
> bvec iter.
> 
> Also rename local variable 'nr_pages' as 'nr_vecs' which exactly matches its
> real usage.
> 
> This patch is based on Mathew's post:
> 
> https://lore.kernel.org/linux-block/20201120123931.GN29991@casper.infradead.org/

But the only reason we want to know 'nr_vecs' is so we can allocate a
BIO which has that many vecs, right?  But we then don't actually use the
vecs in the bio because we use the ones already present in the iter.
That was why I had it return 1, not nr_vecs.

Did I miss something?

> +static inline int bio_iov_iter_nvecs(const struct iov_iter *i, int maxvecs)
> +{
> +	if (!iov_iter_count(i))
> +		return 0;
> +	if (iov_iter_is_bvec(i))
> +               return min_t(int, maxvecs, i->nr_segs);
> +	return iov_iter_npages(i, maxvecs);
> +}

  reply	other threads:[~2020-12-01 12:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-01 12:06 [PATCH] block: add bio_iov_iter_nvecs for figuring out nr_vecs Ming Lei
2020-12-01 12:52 ` Matthew Wilcox [this message]
2020-12-01 12:59   ` Christoph Hellwig
2020-12-01 13:17     ` Pavel Begunkov
2020-12-01 13:32       ` Christoph Hellwig
2020-12-01 13:36         ` Pavel Begunkov
2020-12-01 13:45           ` Christoph Hellwig
2020-12-01 13:48             ` Pavel Begunkov
2020-12-02  2:10             ` Ming Lei
2020-12-02  8:02               ` Christoph Hellwig
2020-12-03 22:36         ` Johannes Weiner
2020-12-03 23:43           ` Pavel Begunkov
2020-12-04 12:48           ` Christoph Hellwig
2020-12-10 13:18             ` Johannes Weiner
2020-12-11 13:22               ` Pavel Begunkov
2020-12-02  1:46   ` Ming Lei
2020-12-02 14:06 ` Pavel Begunkov
2020-12-02 15:02 ` Christoph Hellwig
2020-12-02 16:56 ` Jens Axboe
2020-12-07 18:07 ` Pavel Begunkov
2020-12-08  1:21   ` Ming Lei
2020-12-08  1:50   ` Ming Lei
2020-12-08  2:54     ` Pavel Begunkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201201125251.GA11935@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).