Re: [PATCH v2] EXP rcu: Move expedited grace period (GP) work to RT kthread_worker

From: "Paul E. McKenney" <paulmck@kernel.org>
To: Hillf Danton <hdanton@sina.com>
Cc: Kalesh Singh <kaleshsingh@google.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] EXP rcu: Move expedited grace period (GP) work to RT kthread_worker
Date: Sat, 9 Apr 2022 08:56:12 -0700	[thread overview]
Message-ID: <20220409155612.GO4285@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <20220409071740.6024-1-hdanton@sina.com>

On Sat, Apr 09, 2022 at 03:17:40PM +0800, Hillf Danton wrote:
> On Fri, 8 Apr 2022 10:53:53 -0700 Kalesh Singh wrote
> > Thanks for the discussion everyone.
> > 
> > We didn't fully switch to kthread workers to avoid changing the
> > behavior for users that dont need this low latency exp GPs. Another
> > (and perhaps more important) reason is because kthread_worker offers
> > reduced concurrency than workqueues which Pual reported can pose
> > issues on systems with a large number of CPUs.
> 
> A second ... what issues were reported wrt concurrency, given the output
> of grep -nr workqueue block mm drivers.
> 
> Feel free to post a URL link to the issues.

The issues can be easily seen by inspecting kthread_queue_work() and
the functions that it invokes.  In contrast, normal workqueues uses
per-CPU mechanisms to avoid contention, as can equally easily be seen
by inspecting queue_work_on() and the functions that it invokes.

Please do feel free to take a look.

If taking a look does not convince you, please construct some in-kernel
benchmarks to test the scalability of these two mechanisms.  Please note
that some care will be required to make sure that you are doing a valid
apples-to-apples comparison.

							Thanx, Paul