From: Eric Biggers <ebiggers@kernel.org>
To: "xianrong.zhou(周先荣)" <xianrong.zhou@transsion.com>
Cc: "dm-devel@redhat.com" <dm-devel@redhat.com>,
"weimin.mao(毛卫民)" <weimin.mao@transsion.com>,
"haizhou.song(宋海舟)" <haizhou.song@transsion.com>,
"snitzer@redhat.com" <snitzer@redhat.com>,
"wanbin.wang(汪万斌)" <wanbin.wang@transsion.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"yuanjiong.gao(高渊炯)" <yuanjiong.gao@transsion.com>,
"ruxian.feng(冯儒娴)" <ruxian.feng@transsion.com>,
"agk@redhat.com" <agk@redhat.com>
Subject: Re: [PATCH] dm-verity: unnecessary data blocks that need not read hash blocks
Date: Mon, 16 Dec 2019 10:50:26 -0800 [thread overview]
Message-ID: <20191216185025.GF139479@gmail.com> (raw)
In-Reply-To: <727b9e9279a546beb2ae63a18eae6ab0@transsion.com>
On Mon, Dec 16, 2019 at 02:02:33AM +0000, xianrong.zhou(周先荣) wrote:
> hey Eric:
>
> On Wed, Dec 11, 2019 at 11:32:40AM +0800, zhou xianrong wrote:
> > From: "xianrong.zhou" <xianrong.zhou@transsion.com>
> >
> > If check_at_most_once enabled, just like verity work the prefetching
> > work should check for data block bitmap firstly before reading hash
> > block as well. Skip bit-set data blocks from both ends of data block
> > range by testing the validated bitmap. This can reduce the amounts of
> > data blocks which need to read hash blocks.
> >
> > Launching 91 apps every 15s and repeat 21 rounds on Android Q.
> > In prefetching work we can let only 2602/360312 = 0.72% data blocks
> > really need to read hash blocks.
> >
> > But the reduced data blocks range would be enlarged again by
> > dm_verity_prefetch_cluster later.
> >
> > Signed-off-by: xianrong.zhou <xianrong.zhou@transsion.com>
> > Signed-off-by: yuanjiong.gao <yuanjiong.gao@transsion.com>
> > Tested-by: ruxian.feng <ruxian.feng@transsion.com>
> > ---
> > drivers/md/dm-verity-target.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/md/dm-verity-target.c
> > b/drivers/md/dm-verity-target.c index 4fb33e7562c5..7b8eb754c0b6
> > 100644
> > --- a/drivers/md/dm-verity-target.c
> > +++ b/drivers/md/dm-verity-target.c
> > @@ -581,6 +581,22 @@ static void verity_prefetch_io(struct work_struct *work)
> > struct dm_verity *v = pw->v;
> > int i;
> >
> > + if (v->validated_blocks) {
> > + while (pw->n_blocks) {
> > + if (unlikely(!test_bit(pw->block, v->validated_blocks)))
> > + break;
> > + pw->block++;
> > + pw->n_blocks--;
> > + }
> > + while (pw->n_blocks) {
> > + if (unlikely(!test_bit(pw->block + pw->n_blocks - 1,
> > + v->validated_blocks)))
> > + break;
> > + pw->n_blocks--;
> > + }
> > + if (!pw->n_blocks)
> > + return;
> > + }
>
> This is a good idea, but shouldn't this logic go in verity_submit_prefetch()
> prior to the struct dm_verity_prefetch_work being allocated? Then if no
> prefeching is needed, allocating and scheduling the work object can be
> skipped.
>
> Eric, Do you mean it is more suitable in dm_bufio_prefetch which is called on
> different paths even though prefeching is disabled ?
>
No, I'm talking about verity_submit_prefetch(). verity_submit_prefetch()
allocates and schedules a work object, which executes verity_prefetch_io().
If all data blocks in the I/O request were already validated, there's no need to
allocate and schedule the prefetch work.
- Eric
next prev parent reply other threads:[~2019-12-16 18:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-16 2:02 Reply [PATCH] dm-verity: unnecessary data blocks that need not read hash blocks xianrong.zhou(周先荣)
2019-12-16 18:50 ` Eric Biggers [this message]
2020-01-03 18:24 ` [dm-devel] " Eric Biggers
[not found] <20200107024843.8660-1-zhou_xianrong@sohu.com>
2020-01-07 3:14 ` [PATCH] dm-verity:unnecessary " Eric Biggers
-- strict thread matches above, loose matches on Subject: below --
2019-12-11 3:32 [PATCH] dm-verity: unnecessary " zhou xianrong
2019-12-14 6:58 ` 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=20191216185025.GF139479@gmail.com \
--to=ebiggers@kernel.org \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=haizhou.song@transsion.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ruxian.feng@transsion.com \
--cc=snitzer@redhat.com \
--cc=wanbin.wang@transsion.com \
--cc=weimin.mao@transsion.com \
--cc=xianrong.zhou@transsion.com \
--cc=yuanjiong.gao@transsion.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.