From: Hillf Danton <hdanton@sina.com>
To: Nathan Huckleberry <nhuck@google.com>
Cc: Eric Biggers <ebiggers@kernel.org>,
fsverity@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fsverity: Remove WQ_UNBOUND from fsverity read workqueue
Date: Sat, 11 Mar 2023 08:15:15 +0800 [thread overview]
Message-ID: <20230311001515.2472-1-hdanton@sina.com> (raw)
In-Reply-To: <CAJkfWY6xWhcwfV-E5brz_qvW0v-ebqp8wYhgg_ZWyD9cUp-EJg@mail.gmail.com>
On 10 Mar 2023 11:09:55 -0800 Nathan Huckleberry <nhuck@google.com>
> On Fri, Mar 10, 2023 at 12:01=E2=80=AFAM Hillf Danton <hdanton@sina.com> wr=
> ote:
> >
> > On 9 Mar 2023 21:11:47 -0800 Eric Biggers <ebiggers@kernel.org>
> > > On Thu, Mar 09, 2023 at 01:37:41PM -0800, Nathan Huckleberry wrote:
> > > > WQ_UNBOUND causes significant scheduler latency on ARM64/Android. Th=
> is
> > > > is problematic for latency sensitive workloads like I/O post-processi=
> ng.
> > > >
> > > > Removing WQ_UNBOUND gives a 96% reduction in fsverity workqueue relat=
> ed
> > > > scheduler latency and improves app cold startup times by ~30ms.
> > >
> > > Maybe mention that WQ_UNBOUND was recently removed from the dm-verity w=
> orkqueue
> > > too, for the same reason?
> > >
> > > I'm still amazed that it's such a big improvement! I don't really need=
> it to
> > > apply this patch, but it would be very interesting to know exactly why =
> the
> > > latency is so bad with WQ_UNBOUND.
>
> My current guess for the root cause is excessing saving/restoring of
> the FPSIMD state.
>
> > >
> > > > This code was tested by running Android app startup benchmarks and
> > > > measuring how long the fsverity workqueue spent in the ready queue.
> > > >
> > > > Before
> > > > Total workqueue scheduler latency: 553800us
> > > > After
> > > > Total workqueue scheduler latency: 18962us
> >
> > Given the gap between data above and the 15253 us in diagram[1], and
> > the SHA instructions[2], could you specify a bit on your test?
>
> The test I'm running opens the Android messaging APK which is
> validated with fsverity. It opens the messaging app 25 times, dropping
> caches each time. The benchmark produces a Perfetto trace which we use
> to compute the scheduler latency. We sum up the amount of time that
> each fsverity worker spent in the ready state. The test in [1] is
> similar, but may be using a different APK. These tests are not in
> AOSP, so I can't share a link to them, but I would expect that fio on
> a ramdisk would produce similarly good results.
Thanks for your introduction to the test.
Are the similar results ARM64/Android specific? Could this patch help X86?
>
> >
> > [1] https://lore.kernel.org/linux-erofs/20230106073502.4017276-1-dhavale@=
> google.com/
> > [2] https://lore.kernel.org/lkml/CAJkfWY490-m6wNubkxiTPsW59sfsQs37Wey279L=
> miRxKt7aQYg@mail.gmail.com/
prev parent reply other threads:[~2023-03-11 0:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-09 21:37 [PATCH] fsverity: Remove WQ_UNBOUND from fsverity read workqueue Nathan Huckleberry
2023-03-10 5:11 ` Eric Biggers
2023-03-10 6:55 ` Hillf Danton
2023-03-10 19:09 ` Nathan Huckleberry
2023-03-11 0:15 ` Hillf Danton [this message]
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=20230311001515.2472-1-hdanton@sina.com \
--to=hdanton@sina.com \
--cc=ebiggers@kernel.org \
--cc=fsverity@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=nhuck@google.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 read-only IMAP folder(s) and NNTP newsgroup(s).