Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Tejun Heo <htejun@gmail.com>
Date:   Mon, 26 Jun 2023 10:21:29 -1000
From:   Tejun Heo <tj@kernel.org>
To:     Chuck Lever III <chuck.lever@oracle.com>
Cc:     open list <linux-kernel@vger.kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: contention on pwq->pool->lock under heavy NFS workload
Message-ID: <ZJnzSSMdWhnuXYNE@slm.duckdns.org>
References: <38FA0353-5303-4A3D-86A5-EF1E989CD497@oracle.com>
 <ZJNrht3NlLyPn2A0@slm.duckdns.org>
 <CF5AF0E6-5213-489D-87CD-8E8325A6560F@oracle.com>
 <ZJSfsvFtC_d265M1@slm.duckdns.org>
 <36C8F75A-7C84-4D86-A721-6BCD6001CAFF@oracle.com>
 <7E9EF026-EF8B-4125-AB00-A1E9F0F907C5@oracle.com>
 <ZJZKb4CvyKmHBwmg@slm.duckdns.org>
 <24E8E2D2-F91B-47F6-91BF-02D02750054F@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <24E8E2D2-F91B-47F6-91BF-02D02750054F@oracle.com>
Precedence: bulk

On Sun, Jun 25, 2023 at 04:01:38PM +0000, Chuck Lever III wrote:
> Both wq_pool_mutex and copy_workqueue_attrs() are static, so having
> only apply_workqueue_attrs() is not yet enough to carry this off
> in workqueue consumers such as sunrpc.ko.
> 
> It looks like padata_setup_cpumasks() for example is holding the
> CPU read lock, but it doesn't take the wq_pool_mutex.
> apply_wqattrs_prepare() has a "lockdep_assert_held(&wq_pool_mutex);" .
> 
> I can wait for a v3 of this series so you can construct the public
> API the way you prefer.

Ah, indeed. That API isn't really useable right now. It's gonna be a while
before the affinity scope patches are applied. I'll fix up the apply
interface afterwards.

Thanks.

-- 
tejun