* Thomas Gleixner <t...@linutronix.de> wrote:
> On Thu, 9 Feb 2017, Ingo Molnar wrote:
> >
> > * Peter Zijlstra <pet...@infradead.org> wrote:
> >
> > > On Wed, Feb 08, 2017 at 07:34:18PM +0100, Ingo Molnar wrote:
> > >
> > > > So the original intention of tsk_cpus_allowed() was to 'future-proof'
> > > > the
> > > > field - but it's pretty ineffectual at that, because half of the code
> > > > uses
> > > > ->cpus_allowed directly ...
> > > >
> > > > Also, the wrapper makes the code longer than the original expression!
> > >
> > > I still object to taking this out without replacement.
> >
> > Yeah, that would have been my next suggestion.
> >
> > > This leaves RT stranded.
> >
> > Well, no, it leaves -rt with slightly more patching work than it already
> > has...
> >
> > Because note how the wrappery is _already_ incomplete to a significant
> > degree:
> >
> > triton:~/tip> git grep -Ee '->cpus_allowed' | grep -vE
> > 'tsk_|cpuset|core.c' | wc -l
> > 27
> > triton:~/tip> git grep tsk_cpus_allowed | wc -l
> > 43
> >
> > I.e. around 40% of the places that use ->cpus_allowed in the upstream
> > kernel are
> > not properly wrapped. That fact already 'wrecks' -rt.
>
> Nope it does not. The places which use cpumask directly are not interfering
> with
> the decisions which are made by the scheduler whether migration can happen or
> not. All decision code pathes use the wrapper and we make sure on every
> update
> that this is the case.
Indeed!
> I completely agree that your idea with the const *ptr is the better solution,
> but without that replacement RT is stranded and left alone with the mop up.
Ok, I'm convinced!
Thanks,
Ingo
