From: Mikulas Patocka <mpatocka@redhat.com>
To: LongPing Wei <weilongping@oppo.com>
Cc: snitzer@kernel.org, dm-devel@lists.linux.dev,
guoweichao@oppo.com, ebiggers@kernel.org, bvanassche@acm.org
Subject: Re: [PATCH 2/2] dm-verity: prefetch all hash blocks in verity_ctr
Date: Wed, 2 Apr 2025 20:44:39 +0200 (CEST) [thread overview]
Message-ID: <7228249e-db9d-be26-8459-9141ec3b3ceb@redhat.com> (raw)
In-Reply-To: <d25b56ad-fa6f-49db-9a78-d4849742b22e@oppo.com>
On Wed, 2 Apr 2025, LongPing Wei wrote:
> On 2025/4/2 17:56, Mikulas Patocka wrote:
> >
> >
> > On Wed, 2 Apr 2025, LongPing Wei wrote:
> >
> > > At this time, all bios for hash blocks should eventually
> > > be merged into a single large bio.
> > >
> > > Signed-off-by: LongPing Wei <weilongping@oppo.com>
> > > ---
> > > drivers/md/dm-verity-target.c | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
> > > index 3c427f18a04b..813d5cfc7ffa 100644
> > > --- a/drivers/md/dm-verity-target.c
> > > +++ b/drivers/md/dm-verity-target.c
> > > @@ -1683,6 +1683,10 @@ static int verity_ctr(struct dm_target *ti,
> > > unsigned int argc, char **argv)
> > > verity_verify_sig_opts_cleanup(&verify_args);
> > > + dm_bufio_prefetch_with_ioprio(v->bufio, v->hash_start,
> > > + v->hash_blocks - v->hash_start,
> > > + IOPRIO_PRIO_VALUE(IOPRIO_CLASS_RT, 0));
> > > +
> > > dm_audit_log_ctr(DM_MSG_PREFIX, ti, 1);
> > > return 0;
> > > --
> > > 2.34.1
> >
> > Hi
> >
> > I would move it into the "resume" callback, so that if the user
> > reconfigures the device stack between "ctr" and "resume", it won't read
> > the data too early.
> >
> > Don't use IOPRIO_CLASS_RT, this is not real-time requirement,
> > IOPRIO_CLASS_RT would slow down concurrent I/O.
> >
> If the prefetch io is submitted with non-rt at first, the later dm io
> need the same hash block will wait the non-rt bio.
Submitting large I/O with IOPRIO_CLASS_RT will block every other task that
does some I/O, so I can't do that. It needs to be changed to
IOPRIO_CLASS_NONE or IOPRIO_CLASS_IDLE.
> > Another problem with this approach is that when the verity device is big
> > and system memory is small, it just causes I/O churn - new bufio blocks
> > will be displacing old blocks - and it will degrade performance, not
> > improve it.
> >
> Do we need a solution to check if the memory is enough to the prefetch?
Yes.
> For Android devices, the verity device should be created on the boot
> procedure.
> > Please, describe some scenario, where this prefetch actually helps. What
> > is the size of the metadata that you are prefetching? What is the total
> > memory size? Is there any benchmark that shows the advantage of this
> > patch?
>
> The size of hash blocks for the ROM of our low-end devices is about
> 71MiB. I want to enhance probability of cache hit when
> try_verify_in_tasklet is enabled. How about only doing the prefetch when
> try_verify_in_tasklet is enabled?
> For example:
> if (v->use_bh_wq)
> dm_bufio_prefetch_with_ioprio(v->bufio, v->hash_start,
> v->hash_blocks - v->hash_start,
> IOPRIO_PRIO_VALUE(IOPRIO_CLASS_RT, 0));
I wouldn't overload the "use_bh_wq" option for that. Perhaps we could add
a new option (that would be off by default), so that the patch won't cause
problems to existing users.
How much does this patch improve Android boot time? So that we can decide
whether the improvement is worth the complexity.
Mikulas
next prev parent reply other threads:[~2025-04-02 18:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 7:09 [PATCH 1/2] dm-bufio: improve the performance of __dm_bufio_prefetch LongPing Wei
2025-04-02 7:09 ` [PATCH 2/2] dm-verity: prefetch all hash blocks in verity_ctr LongPing Wei
2025-04-02 9:56 ` Mikulas Patocka
2025-04-02 10:35 ` LongPing Wei
2025-04-02 18:44 ` Mikulas Patocka [this message]
2025-04-02 23:58 ` LongPing Wei
2025-04-10 8:28 ` Christoph Hellwig
2025-04-10 8:26 ` Christoph Hellwig
2025-04-02 17:43 ` [PATCH 1/2] dm-bufio: improve the performance of __dm_bufio_prefetch Eric Biggers
2025-04-03 0:12 ` LongPing Wei
2025-04-10 8:29 ` Christoph Hellwig
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=7228249e-db9d-be26-8459-9141ec3b3ceb@redhat.com \
--to=mpatocka@redhat.com \
--cc=bvanassche@acm.org \
--cc=dm-devel@lists.linux.dev \
--cc=ebiggers@kernel.org \
--cc=guoweichao@oppo.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.