From: Nathan Huckleberry <nhuck@google.com>
To: Tejun Heo <tj@kernel.org>
Cc: Sandeep Dhavale <dhavale@google.com>,
Daeho Jeong <daehojeong@google.com>,
Eric Biggers <ebiggers@kernel.org>,
Sami Tolvanen <samitolvanen@google.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] workqueue: Add WQ_SCHED_FIFO
Date: Fri, 27 Jan 2023 11:25:10 -0800 [thread overview]
Message-ID: <CAJkfWY490-m6wNubkxiTPsW59sfsQs37Wey279LmiRxKt7aQYg@mail.gmail.com> (raw)
In-Reply-To: <Y8iq6gLtmX1c8VSf@slm.duckdns.org>
On Wed, Jan 18, 2023 at 6:29 PM Tejun Heo <tj@kernel.org> wrote:
>
> Hello,
>
> On Wed, Jan 18, 2023 at 06:01:04PM -0800, Nathan Huckleberry wrote:
> > Do you think something similar should be done for WQ_UNBOUND? In most
> > places where WQ_HIGHPRI is used, WQ_UNBOUND is also used because it
> > boosts performance. However, I suspect that most of these benchmarks
> > were done on x86-64. I've found that WQ_UNBOUND significantly reduces
> > performance on arm64/Android.
>
> One attribute with per-cpu workqueues is that they're concurrency-level
> limited. ie. if you have two per-cpu work items queued, the second one might
> not run until the first one is done. Maybe people were trying to avoid
> possible latency spikes from that?
>
> Even aside from that, UNBOUND tends to give more consistent latency
> behaviors as you aren't necessarily bound to what's happening on that
> particular, so I guess maybe that's also why but I didn't really follow how
> each user is picking and justifying these flags, so my insight is pretty
> limited.
>
> > From the documentation, using WQ_UNBOUND for performance doesn't seem
> > correct. It's only supposed to be used for long-running work. It might
> > make more sense to get rid of WQ_UNBOUND altogether and only move work
> > to unbound worker pools once it has stuck around for long enough.
>
> UNBOUND says: Don't pin this to one cpu or subject it to workqueue's
> concurrency limit. Use workqueue as a generic thread pool.
>
> I don't know what you mean by performance but HIGHPRI | UNBOUND will
> definitely improve some aspects.
>
> > Android will probably need to remove WQ_UNBOUND from all of these
> > performance critical users.
> >
> > If there are performance benefits to using unbinding workqueues from
> > CPUs on x86-64, that should probably be a config flag, not controlled
> > by every user.
>
> It's unlikely that the instruction set is what's making the difference here,
> right? It probably would help if we understand why it's worse on arm.
I did some more digging. For dm-verity I think this is related to the
availability of SHA instructions. If SHA instructions are present,
WQ_UNBOUND is suboptimal because the work finishes very quickly.
That doesn't explain why EROFS is slower with WQ_UNBOUND though.
It might also be related to the heterogeneity of modern arm
processors. Locality may be more important for ARM processors than for
x86-64.
See the table below:
| open-prebuilt-camera | UNBOUND | HIGHPRI | HIGHPRI ONLY | SCHED_FIFO ONLY |
| erofs wait time (us) | 357805 | 174205
(-51%) | 129861 (-63%) |
| verity wait time (us) | 11746 | 119
(-98%) | 0 (-100%) |
The bigger issue seems to be WQ_UNBOUND, so I'm abandoning these
patches for now.
Thanks,
Huck
>
> I don't think ppl have been all that deliberate with these flags, so it's
> also likely that some of the usages can drop UNBOUND completely but I really
> think more data and analyses would help.
>
> Thanks.
>
> --
> tejun
next prev parent reply other threads:[~2023-01-27 19:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 21:07 [PATCH] workqueue: Add WQ_SCHED_FIFO Nathan Huckleberry
2023-01-13 21:11 ` Tejun Heo
2023-01-14 21:00 ` Nathan Huckleberry
2023-01-18 17:51 ` Tejun Heo
2023-01-18 18:22 ` Sandeep Dhavale
2023-01-18 18:25 ` Tejun Heo
2023-01-18 22:04 ` Nathan Huckleberry
2023-01-19 2:01 ` Nathan Huckleberry
2023-01-19 2:28 ` Tejun Heo
2023-01-27 19:25 ` Nathan Huckleberry [this message]
2023-01-14 2:19 ` Gao Xiang
2023-01-14 21:00 ` Nathan Huckleberry
2023-01-19 2:41 ` Sandeep Dhavale
2023-01-19 4:31 ` Gao Xiang
2023-02-12 13:56 ` kernel test robot
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=CAJkfWY490-m6wNubkxiTPsW59sfsQs37Wey279LmiRxKt7aQYg@mail.gmail.com \
--to=nhuck@google.com \
--cc=corbet@lwn.net \
--cc=daehojeong@google.com \
--cc=dhavale@google.com \
--cc=ebiggers@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=samitolvanen@google.com \
--cc=tj@kernel.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).