lkml.org 
[lkml]   [2017]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU mask

* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Thu, 6 Apr 2017, Ingo Molnar wrote:
> > CPU hotplug and changing the affinity mask are the more complex cases, because
> > there migrating or not migrating is a correctness issue:
> >
> > - CPU hotplug has to be aware of this anyway, regardless of whether it's solved
> > via a counter of the affinity mask.
>
> You have to prevent CPU hotplug simply as long as there are migration disabled
> tasks on the fly. Making that depend on whether they are on a CPU which is about
> to be unplugged or not would be complete overkill as you still have to solve the
> case that a task sets the migrate_disable() AFTER the cpu down machinery
> started.
>
> [...]
>
> The counter alone might be enough for the scheduler placement decisions, but it
> cannot solve the hotplug issue. You still need something like I sketched out in
> my previous reply.

Yes, so what you outlined:

void migrate_disable(void)
{
if (in_atomic() || irqs_disabled())
return;

if (!current->migration_disabled) {
percpu_down_read_preempt_disable(hotplug_rwsem);
current->migration_disabled++;
preempt_enable();
} else {
current->migration_disabled++;
}
}

Would solve it?

I.e. my point is: whether migrate_disable()/enable() is implemented via a counter
or a pointer to a cpumask does not materially change how the CPU-hotplug solution
looks like, right?

I.e. we could just use the counter and avoid the whole wrapping of cpumask
complexity.

Thanks,

Ingo

\
 
 \ /
  Last update: 2017-04-07 09:14    [W:0.058 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site