[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1486383511.10462.43.camel@gmx.de>
Date: Mon, 06 Feb 2017 13:18:31 +0100
From: Mike Galbraith <efault@....de>
To: Ingo Molnar <mingo@...nel.org>
Cc: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed()
On Mon, 2017-02-06 at 11:31 +0100, Ingo Molnar wrote:
> * Mike Galbraith <efault@....de> wrote:
>
> > Hi Ingo,
> >
> > Doing my ~daily tip merge of -rt, I couldn't help noticing $subject, as
> > they grow more functionality in -rt, which is allegedly slowly but
> > surely headed toward merge. I don't suppose they could be left intact?
> > I can easily restore them in my local tree, but it seems a bit of a
> > shame to whack these integration friendly bits.
>
> Oh, I missed that. How is tsk_cpus_allowed() wrapped in -rt right now?
RT extends them to reflect whether migration is disabled or not.
+/* 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;
+}
Powered by blists - more mailing lists