Re: [RFC PATCH v2 4/4] arm64: Export id_aar64fpr0 via sysfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/21/20 15:33, Morten Rasmussen wrote:
> On Wed, Oct 21, 2020 at 01:15:59PM +0100, Catalin Marinas wrote:
> > 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



[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux