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,The current behavior is not something which is carefully planned. It's more
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
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 writtenBut yeah, that sounds acceptable.
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.