linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Pavel Begunkov <asml.silence@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Matthew Wilcox <willy@infradead.org>,
	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, 8 Dec 2020 09:21:17 +0800	[thread overview]
Message-ID: <20201208012117.GA1059392@T590> (raw)
In-Reply-To: <3eb1020d-c336-dbe6-d75e-70c388464e6e@gmail.com>

On Mon, Dec 07, 2020 at 06:07:39PM +0000, Pavel Begunkov wrote:
> On 01/12/2020 12:06, 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:
> 
> Tried this, the system didn't boot + discovered a filesystem blowned after
> booting with a stable kernel. That's on top of 4498a8536c816 ("block: use
> an xarray for disk->part_tbl"), which works fine. Ideas?

Is share any log to show the issue?

Can you share us the kernel .config? And what is your root disk? Not see
any issue on this kernel in my KVM test.


Thanks,
Ming


  reply	other threads:[~2020-12-08  1:23 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
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 [this message]
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=20201208012117.GA1059392@T590 \
    --to=ming.lei@redhat.com \
    --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=willy@infradead.org \
    /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).