Messages in this thread | | | Date | Fri, 7 Apr 2017 09:13:23 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |