From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754183AbdDGHNf (ORCPT <rfc822;w@1wt.eu>);
        Fri, 7 Apr 2017 03:13:35 -0400
Received: from mail-wr0-f194.google.com ([209.85.128.194]:36089 "EHLO
        mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753038AbdDGHN1 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 7 Apr 2017 03:13:27 -0400
Date: Fri, 7 Apr 2017 09:13:23 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        linux-kernel@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
        Mike Galbraith <efault@gmx.de>, Ingo Molnar <mingo@elte.hu>,
        "Rafael J . Wysocki" <rjw@rjwysocki.net>
Subject: Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU
 mask
Message-ID: <20170407071323.GA5360@gmail.com>
References: <20170404184202.20376-1-bigeasy@linutronix.de>
 <20170405073943.GA17266@gmail.com>
 <20170405083753.7eszej2njds4ovdb@linutronix.de>
 <20170406061622.GA19979@gmail.com>
 <20170406073832.e7bu4ldpfuq44ui6@linutronix.de>
 <20170406080139.GA22069@gmail.com>
 <alpine.DEB.2.20.1704061052370.1716@nanos>
 <20170406110215.GA1367@gmail.com>
 <alpine.DEB.2.20.1704061304340.1716@nanos>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1704061304340.1716@nanos>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* 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