Messages in this thread | | | Date | Mon, 5 Feb 2024 07:30:17 +0100 | From | Juri Lelli <> | Subject | Re: [RFC PATCH 0/3] workqueue: Enable unbound cpumask update on ordered workqueues |
| |
On 02/02/24 14:03, Waiman Long wrote: > On 2/2/24 12:07, Tejun Heo wrote: > > Hello, > > > > On Fri, Feb 02, 2024 at 03:55:15PM +0100, Juri Lelli wrote: > > > Indeed. I believe this is what my 3/4 [1] was trying to cure, though. I > > > still think that with current code the new_attr->cpumask gets first > > > correctly initialized considering unbound_cpumask > > > > > > apply_wqattrs_prepare -> > > > copy_workqueue_attrs(new_attrs, attrs); > > > wqattrs_actualize_cpumask(new_attrs, unbound_cpumask); > > > > > > but then overwritten further below using cpu_possible_mask > > > > > > apply_wqattrs_prepare -> > > > copy_workqueue_attrs(new_attrs, attrs); > > > cpumask_and(new_attrs->cpumask, new_attrs->cpumask, cpu_possible_mask); > > > > > > operation that I honestly seem to still fail to grasp why we need to do. > > > :) > > So, imagine the following scenario on a system with four CPUs: > > > > 1. Initially both wq_unbound_cpumask and wq A's cpumask are 0xf. > > > > 2. wq_unbound_cpumask is set to 0x3. A's effective is 0x3. > > > > 3. A's cpumask is set to 0xe, A's effective is 0x3. > > > > 4. wq_unbound_cpumask is restore to 0xf. A's effective should become 0xe. > > > > The reason why we're saving what user requested rather than effective is to > > be able to do #4 so that the effective is always what's currently allowed > > from what the user specified for the workqueue.
Thanks for the explanation!
> > Now, if you want the current effective cpumask, that always coincides with > > the workqueue's dfl_pwq's __pod_cpumask and if you look at the current > > wq/for-6.9 branch, that's accessible through unbound_effective_cpumask() > > helper. > > Thank for the explanation, we will use the new unbound_effective_cpumask() > helper.
Right, that should indeed work.
Best, Juri
| |