On 10/21/20 15:33, Morten Rasmussen wrote:

On Wed, Oct 21, 2020 at 01:15:59PM +0100, Catalin Marinas wrote:

quoted

one, though not as easy as automatic task placement by the scheduler (my
first preference, followed by the id_* regs and the aarch32 mask, though
not a strong preference for any).

Automatic task placement by the scheduler would mean giving up the
requirement that the user-space affinity mask must always be honoured.
Is that on the table?

Killing aarch32 tasks with an empty intersection between the user-space
mask and aarch32_mask is not really "automatic" and would require the
aarch32 capability to be exposed anyway.

I just noticed this nasty corner case too.


Documentation/admin-guide/cgroup-v1/cpusets.rst: Section 1.9

"If such a task had been bound to some subset of its cpuset using the
sched_setaffinity() call, the task will be allowed to run on any CPU allowed in
its new cpuset, negating the effect of the prior sched_setaffinity() call."


So user space must put the tasks into a valid cpuset to fix the problem. Or
make the scheduler behave like the affinity is associated with a cpuset.

Can user space put the task into the correct cpuset without a race? Clone3
syscall learnt to specify a cgroup to attach to when forking. Should we do the
same for execve()?


Thanks

--
Qais Yousef

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel