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
