From: Eric Biggers <ebiggers@kernel.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: LongPing Wei <weilongping@oppo.com>,
agk@redhat.com, dm-devel@lists.linux.dev, guoweichao@oppo.com,
snitzer@kernel.org, Bart Van Assche <bvanassche@acm.org>
Subject: Re: [PATCH v2] dm-verity: support block number limits for different ioprio classes
Date: Thu, 27 Mar 2025 17:35:10 +0000 [thread overview]
Message-ID: <20250327173510.GA3371050@google.com> (raw)
In-Reply-To: <6421ae31-5b4a-f35a-724c-1970ec3ab06b@redhat.com>
On Thu, Mar 27, 2025 at 06:12:22PM +0100, Mikulas Patocka wrote:
>
>
> On Thu, 27 Mar 2025, Eric Biggers wrote:
>
> > > Hi, Eric
> > >
> > > It seems that verity_prefetch_io doesn't work efficiently.
> > > dm_bufio_prefetch_with_ioprio
> > > __dm_bufio_prefetch
> > > blk_start_plug
> > > for loop
> > > __bufio_new
> > > submit_io
> > > cond_resched
> > > blk_finish_plug
> > >
> > > If more than one hash blocks need to be prefetched, cond_resched will
> > > be called in each loop and blk_finish_plug will be called at the end.
> > >
> > > The requests for hash blocks may have not been dispatched when the
> > > requests for data blocks have been completed.
> >
> > Well, it's always possible for the prefetch I/O to be too slow, but the way it
> > works does seem to be unnecessarily bad. The prefetch work runs on a kworker,
> > which is going to slow things down. The way it should work is that verity_map()
> > runs the prefetch work and starts, but doesn't wait for, any I/O that is needed.
> > (And of course, most of the time no I/O will actually be needed.)
> >
> > - Eric
>
> dm-verity used to prefetch from the verity_map function, but it caused a
> deadlock - 3b6b7813b198b578aa7e04e4047ddb8225c37b7f - so, it was moved to
> a workqueue.
Interesting. Unfortunately I think the workqueue makes it way worse.
In principle there is no need for it to block for anything. If it would have to
block, it just should just continue on.
- Eric
next prev parent reply other threads:[~2025-03-27 17:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 10:49 [PATCH] dm-verity: support block number limits for different ioprio classes LongPing Wei
2025-03-25 17:43 ` Eric Biggers
2025-03-26 2:09 ` LongPing Wei
2025-03-26 16:40 ` Eric Biggers
2025-03-25 21:17 ` Mikulas Patocka
2025-03-26 1:30 ` [PATCH v2] " LongPing Wei
2025-03-26 5:18 ` Eric Biggers
2025-03-26 6:34 ` LongPing Wei
2025-03-26 11:04 ` Mikulas Patocka
2025-03-26 13:32 ` LongPing Wei
2025-03-26 16:53 ` Eric Biggers
2025-03-26 18:50 ` Mikulas Patocka
2025-03-26 20:32 ` Bart Van Assche
2025-03-26 20:48 ` Eric Biggers
2025-03-27 0:52 ` LongPing Wei
2025-03-27 17:05 ` Eric Biggers
2025-03-27 17:12 ` Mikulas Patocka
2025-03-27 17:35 ` Eric Biggers [this message]
2025-03-27 19:03 ` Mikulas Patocka
2025-03-27 19:39 ` Mikulas Patocka
2025-03-27 2:18 ` [PATCH v3] " LongPing Wei
2025-03-27 16:16 ` Mikulas Patocka
2025-03-27 16:57 ` Eric Biggers
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=20250327173510.GA3371050@google.com \
--to=ebiggers@kernel.org \
--cc=agk@redhat.com \
--cc=bvanassche@acm.org \
--cc=dm-devel@lists.linux.dev \
--cc=guoweichao@oppo.com \
--cc=mpatocka@redhat.com \
--cc=snitzer@kernel.org \
--cc=weilongping@oppo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.