Received-SPF: pass (google.com: domain of linux-kernel+bounces-29365-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <72e4a971-96e5-44b7-b348-bbdb68e54b40@redhat.com>
Date: Wed, 17 Jan 2024 14:32:34 -0500
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 3/4] kernel/workqueue: Distinguish between general
 unbound and WQ_SYSFS cpumask changes
Content-Language: en-US
To: Tejun Heo <tj@kernel.org>, Juri Lelli <juri.lelli@redhat.com>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>, Aaron Tomlin
 <atomlin@atomlin.com>, Valentin Schneider <vschneid@redhat.com>,
 linux-kernel@vger.kernel.org
References: <20240116161929.232885-1-juri.lelli@redhat.com>
 <20240116161929.232885-4-juri.lelli@redhat.com>
 <ZabRlEklmuqwFPj-@slm.duckdns.org> <ZafQwMw8ZKztunMU@localhost.localdomain>
 <ZagKbRlBxZHsKiw5@mtj.duckdns.org>
From: Waiman Long <longman@redhat.com>
In-Reply-To: <ZagKbRlBxZHsKiw5@mtj.duckdns.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 1/17/24 12:12, Tejun Heo wrote:
> Hello,
>
> On Wed, Jan 17, 2024 at 02:06:08PM +0100, Juri Lelli wrote:
>>> This looks rather hacky. Can you elaborate how the current code misbehaves
>>> with an example?
>> I was trying to address the fact that ordered unbound workqueues didn't
>> seem to reflect unbound_cpumask changes, e.g.
>>
>> wq_unbound_cpumask=00000003
>>
>> edac-poller              ordered,E  0xffffffff 000000ff      kworker/R-edac-            351 0xffffffff 000000ff
>>
>> vs.
>>
>> edac-poller              ordered,E  00000003                 kworker/R-edac-            349 00000003
>>
>> with the patch applied. But honestly, I'm now also not convinced what
>> I'm proposing is correct, so I'll need to think more about it.
>>
>> Can you please confirm though that ordered unbound workqueues are not
>> "special" for some reason and we would like them to follow
>> unbound_cpumask changes as normal ubound workqueues?
> They aren't special and should follow the normal unbound workqueue cpumask.

My impression is that changing the workqueue cpumask of ordered unbound 
workqueue may break the ordering guarantee momentarily. I was planning 
to look into this further to see if that is true when I have time. If it 
is not a concern, we should certainly apply the global unbound cpumask 
change to those workqueues as well.

Cheers,
Longman