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.
