On 10/23/23 23:28, Tejun Heo wrote:
Hello,
On Wed, Oct 18, 2023 at 03:18:52PM -0400, Waiman Long wrote:
I have a second thought after taking a further look at that. First of all, cpuset_allowed_mask isn't relevant here and the mask can certainly contain offline CPUs. So cpu_possible_mask is the proper fallback.
With the current patch, wq_user_unbound_cpumask is set up initially as (HK_TYPE_WQ ∩ HK_TYPE_DOMAIN) house keeping mask and rewritten by any subsequent write to workqueue/cpumask sysfs file. So using
The current behavior is not something which is carefully planned. It's more accidental than anything. If we can come up with a more intutive and consistent behavior, that should be fine.
wq_user_unbound_cpumask has the implied precedence of user-sysfs written mask, command line isolcpus or nohz_full option mask and cpu_possible_mask. I think just fall back to wq_user_unbound_cpumask if the operation fails should be enough.
But yeah, that sounds acceptable.
I have implemented the fallback to the user requested cpumask in the failure case.
Cheers, Longman