On 10/09/20 11:25, Peter Zijlstra wrote: > On Fri, Oct 09, 2020 at 10:13:12AM +0200, Morten Rasmussen wrote: > > On Fri, Oct 09, 2020 at 09:29:43AM +0200, Peter Zijlstra wrote: > > > > Fundamentally, you're not supposed to change the userspace provided > > > affinity mask. If we want to do something like this, we'll have to teach > > > the scheduler about this second mask such that it can compute an > > > effective mask as the intersection between the 'feature' and user mask. > > > > I agree that we shouldn't mess wit the user-space mask directly. Would it > > be unthinkable to go down the route of maintaining a new mask which is > > the intersection of the feature mask (controlled and updated by arch > > code) and the user-space mask? > > > > It shouldn't add overhead in the scheduler as it would use the > > intersection mask instead of the user-space mask, the main complexity > > would be around making sure the intersection mask is updated correctly > > (cpusets, hotplug, ...). > > IFF we _need_ to go there, then yes that was the plan, compose the > intersection when either the (arch) feature(set) mask or the userspace > mask changes. On such systems these tasks are only valid to run on a subset of cpus. It makes a lot of sense to me if we want to go down that route to fixup the affinity when a task is spawned and make sure sched_setaffinity() never allows it to go outside this range. The tasks can't physically run on those cpus, so I don't see us breaking user-space affinity here. Just reflecting the reality. Only if it moved to a cpuset with no intersection it would be killed. Which I think is the behavior anyway today. Thanks -- Qais Yousef
