[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1702081107450.3536@nanos>
Date: Wed, 8 Feb 2017 11:20:19 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Ingo Molnar <mingo@...nel.org>
cc: Peter Zijlstra <peterz@...radead.org>,
Mike Galbraith <efault@....de>, Ingo Molnar <mingo@...e.hu>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed()
On Mon, 6 Feb 2017, Ingo Molnar wrote:
> * Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > cpumasks are a pain, the above avoids allocating more of them.
Indeed.
> Yeah, so this could then be done by pointerifying ->cpus_allowed - more robust
> than the wrappery,
You mean:
struct task_struct {
cpumask_t cpus_allowed;
cpumask_t *effective_cpus_allowed;
};
and make the scheduler use effective_cpus_allowed instead of cpus_allowed?
Or what do you have in mind?
> because as I've noted in the changelog there's a large body of
> upstream code that does not use the wrappers but uses ->cpus_allowed directly:
Right and we really should audit those places. I bet that half of them are
just broken and evil hacks.
The wrapper we added is just covering the core scheduler code where the
information really matters for decision, but leaves the other oddball cases
alone.
The extra pointer might be a nicer concept, but it still has the same issue
as the wrapper. How do we enforce that random code accesses the right
thing?
Thanks,
tglx
Powered by blists - more mailing lists