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 S1752855AbdBFNcy (ORCPT <rfc822;w@1wt.eu>);
        Mon, 6 Feb 2017 08:32:54 -0500
Received: from bombadil.infradead.org ([65.50.211.133]:55941 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750980AbdBFNcw (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 6 Feb 2017 08:32:52 -0500
Date: Mon, 6 Feb 2017 14:32:42 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Mike Galbraith <efault@gmx.de>, Ingo Molnar <mingo@elte.hu>,
        Thomas Gleixner <tglx@linutronix.de>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed()
Message-ID: <20170206133242.GK6515@twins.programming.kicks-ass.net>
References: <1486355037.10462.17.camel@gmx.de>
 <20170206103156.GA18908@gmail.com>
 <1486383511.10462.43.camel@gmx.de>
 <20170206122928.GB9404@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170206122928.GB9404@gmail.com>
User-Agent: Mutt/1.5.23.1 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Feb 06, 2017 at 01:29:28PM +0100, Ingo Molnar wrote:
> > +/* Future-safe accessor for struct task_struct's cpus_allowed. */
> > +static inline const struct cpumask *tsk_cpus_allowed(struct task_struct *p)
> > +{
> > +       if (__migrate_disabled(p))
> > +               return cpumask_of(task_cpu(p));
> > +
> > +       return &p->cpus_allowed;
> > +}
> > +
> > +static inline int tsk_nr_cpus_allowed(struct task_struct *p)
> > +{
> > +       if (__migrate_disabled(p))
> > +               return 1;
> > +       return p->nr_cpus_allowed;
> > +}
> 
> So ... I think the cleaner approach in -rt would be to introduce 
> ->cpus_allowed_saved, and when disabling/enabling migration then saving the 
> current mask there and changing ->cpus_allowed - and then restoring it when 
> re-enabling migration.
> 
> This means ->cpus_allowed could be used by the scheduler directly, no wrappery 
> would be required, AFAICS.
> 
> ( Some extra care would be required in places that change ->cpus_allowed because 
>   they'd now have to be aware of ->cpus_allowed_saved. )
> 
> Am I missing something?

cpumasks are a pain, the above avoids allocating more of them.