Messages in this thread | | | Date | Thu, 26 Mar 2020 17:52:40 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH v2] isolcpus: affine kernel threads to specified cpumask |
| |
On Thu, Mar 26, 2020 at 05:20:05PM +0100, Frederic Weisbecker wrote: > On Wed, Mar 25, 2020 at 08:47:36AM -0300, Marcelo Tosatti wrote: > > > > Hi Frederic, > > > > On Wed, Mar 25, 2020 at 01:30:00AM +0100, Frederic Weisbecker wrote: > > > On Tue, Mar 24, 2020 at 12:20:16PM -0300, Marcelo Tosatti wrote: > > > > > > > > This is a kernel enhancement to configure the cpu affinity of kernel > > > > threads via kernel boot option isolcpus=no_kthreads,<isolcpus_params>,<cpulist> > > > > > > > > When this option is specified, the cpumask is immediately applied upon > > > > thread launch. This does not affect kernel threads that specify cpu > > > > and node. > > > > > > > > This allows CPU isolation (that is not allowing certain threads > > > > to execute on certain CPUs) without using the isolcpus=domain parameter, > > > > making it possible to enable load balancing on such CPUs > > > > during runtime (see > > > > > > > > Note-1: this is based off on Wind River's patch at > > > > https://github.com/starlingx-staging/stx-integ/blob/master/kernel/kernel-std/centos/patches/affine-compute-kernel-threads.patch > > > > > > > > Difference being that this patch is limited to modifying > > > > kernel thread cpumask: Behaviour of other threads can > > > > be controlled via cgroups or sched_setaffinity. > > > > > > > > Note-2: MontaVista's patch was based off Christoph Lameter's patch at > > > > https://lwn.net/Articles/565932/ with the only difference being > > > > the kernel parameter changed from kthread to kthread_cpus. > > > > > > > > Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> > > > > > > I'm wondering, why do you need such a boot shift at all when you > > > can actually affine kthreads on runtime? > > > > New, unbound kernel threads inherit the cpumask of kthreadd. > > > > Therefore there is a race between kernel thread creation > > and affine. > > > > If you know of a solution to that problem, that can be used instead. > > Well, you could first set the affinity of kthreadd and only then the affinity > of the others. But I can still imagine some tiny races with fork().
Ah forget that, I missed the part in kthread_create_on_node().
Thanks.
| |