From: Tejun Heo <tj@kernel.org>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Frederic Weisbecker <frederic@kernel.org>,
Joe Mario <jmario@redhat.com>, Juri Lelli <juri.lelli@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mark power efficient workqueue as unbounded if nohz_full enabled
Date: Tue, 23 Jan 2024 08:56:53 -1000 [thread overview]
Message-ID: <ZbAL9WBNkKuaZjHj@slm.duckdns.org> (raw)
In-Reply-To: <Za56EiAI9D5S8NuT@tpad>
Hello, Marcelo.
On Mon, Jan 22, 2024 at 11:22:10AM -0300, Marcelo Tosatti wrote:
> About the performance difference (of running locally VS running
> remotely), can you list a few performance sensitive work queues
> (where per-CPU execution makes a significant difference).
Unfortunately, I have no idea. It goes way back and I'm not sure anyone
actually tested the difference in a long time. We'd have to dig through
history to gather some context, set up a benchmark which exercises the path
heavily and see whether the difference is still there.
> Because i suppose it would be safe (from a performance regression
> perspective) to move all delayed works to housekeeping CPUs.
Yeah, replacing power_efficient with unbound should be safe.
> And also, being more extreme, why not an option to mark all workqueues
> as unbounded (or perhaps userspace control of bounding, even for
> workqueues marked as "per-CPU").
There are correctness issues with per-cpu workqueues - e.g. accessing local
atomic counters, cpu states and what not. Also, many per-cpu users already
know that the cpu is hot as they're queueing on the local CPU. I'm not
against moving more users towards unbound workqueues but that'd have be done
case by case unfortunately.
Thanks.
--
tejun
prev parent reply other threads:[~2024-01-23 18:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-19 15:54 Marcelo Tosatti
2024-01-19 23:57 ` Tejun Heo
2024-01-22 14:22 ` Marcelo Tosatti
2024-01-23 18:56 ` Tejun Heo [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=ZbAL9WBNkKuaZjHj@slm.duckdns.org \
--to=tj@kernel.org \
--cc=frederic@kernel.org \
--cc=jmario@redhat.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.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
all inboxes | Powered by JetHome®