Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1574628

Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed()

Show all headers | View raw

* Mike Galbraith <efault@gmx.de> wrote:

> On Mon, 2017-02-06 at 11:31 +0100, Ingo Molnar wrote:
> > * Mike Galbraith <efault@gmx.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;
> +}

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?

	Ingo

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed() Mike Galbraith <efault@gmx.de> - 2017-02-06 05:30 +0100
  Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed() Ingo Molnar <mingo@kernel.org> - 2017-02-06 11:40 +0100
    Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed() Mike Galbraith <efault@gmx.de> - 2017-02-06 13:20 +0100
      Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed() Ingo Molnar <mingo@kernel.org> - 2017-02-06 13:30 +0100
        Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed() Mike Galbraith <efault@gmx.de> - 2017-02-06 13:50 +0100
        Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed() Peter Zijlstra <peterz@infradead.org> - 2017-02-06 14:40 +0100
          Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed() Ingo Molnar <mingo@kernel.org> - 2017-02-06 23:30 +0100
            Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed() Thomas Gleixner <tglx@linutronix.de> - 2017-02-08 12:10 +0100
              Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed() Peter Zijlstra <peterz@infradead.org> - 2017-02-08 13:40 +0100
                Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed() Ingo Molnar <mingo@kernel.org> - 2017-02-09 08:00 +0100
                Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed() Peter Zijlstra <peterz@infradead.org> - 2017-02-09 10:00 +0100
                Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed() Thomas Gleixner <tglx@linutronix.de> - 2017-02-09 10:40 +0100
                Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed() Ingo Molnar <mingo@kernel.org> - 2017-02-09 08:20 +0100

csiph-web