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


Groups > linux.kernel > #1618517

Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU mask

From Ingo Molnar <mingo@kernel.org>
Newsgroups linux.kernel
Subject Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU mask
Date 2017-04-07 09:20 +0200
Message-ID <ttwlA-40I-13@gated-at.bofh.it> (permalink)
References (4 earlier) <ttabo-5wO-27@gated-at.bofh.it> <ttaEq-5XA-9@gated-at.bofh.it> <ttcZA-7iO-19@gated-at.bofh.it> <ttdsC-7HU-7@gated-at.bofh.it> <ttdCh-7Mq-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Thu, 6 Apr 2017, Ingo Molnar wrote:
> > CPU hotplug and changing the affinity mask are the more complex cases, because 
> > there migrating or not migrating is a correctness issue:
> > 
> >  - CPU hotplug has to be aware of this anyway, regardless of whether it's solved 
> >    via a counter of the affinity mask.
> 
> You have to prevent CPU hotplug simply as long as there are migration disabled 
> tasks on the fly. Making that depend on whether they are on a CPU which is about 
> to be unplugged or not would be complete overkill as you still have to solve the 
> case that a task sets the migrate_disable() AFTER the cpu down machinery 
> started.
>
> [...]
>
> The counter alone might be enough for the scheduler placement decisions, but it 
> cannot solve the hotplug issue. You still need something like I sketched out in 
> my previous reply.

Yes, so what you outlined:

void migrate_disable(void)
{
        if (in_atomic() || irqs_disabled())
                return;

        if (!current->migration_disabled) {
                percpu_down_read_preempt_disable(hotplug_rwsem);
                current->migration_disabled++;
                preempt_enable();
        } else {
                current->migration_disabled++;
        }
}

Would solve it?

I.e. my point is: whether migrate_disable()/enable() is implemented via a counter 
or a pointer to a cpumask does not materially change how the CPU-hotplug solution 
looks like, right?

I.e. we could just use the counter and avoid the whole wrapping of cpumask 
complexity.

Thanks,

	Ingo

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


Thread

[RFC PATCH] kernel: sched: Provide a pointer to the valid CPU mask Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2017-04-04 20:50 +0200
  Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Ingo Molnar <mingo@kernel.org> - 2017-04-05 09:40 +0200
    Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2017-04-05 10:40 +0200
      Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Ingo Molnar <mingo@kernel.org> - 2017-04-06 08:20 +0200
        Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2017-04-06 09:40 +0200
          Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Ingo Molnar <mingo@kernel.org> - 2017-04-06 10:10 +0200
            Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2017-04-06 11:30 +0200
              Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Peter Zijlstra <peterz@infradead.org> - 2017-04-06 11:50 +0200
                Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Thomas Gleixner <tglx@linutronix.de> - 2017-04-06 13:00 +0200
                Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Peter Zijlstra <peterz@infradead.org> - 2017-04-06 13:50 +0200
            Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Peter Zijlstra <peterz@infradead.org> - 2017-04-06 11:40 +0200
              Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Peter Zijlstra <peterz@infradead.org> - 2017-04-06 11:50 +0200
            Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Thomas Gleixner <tglx@linutronix.de> - 2017-04-06 12:40 +0200
              Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Ingo Molnar <mingo@kernel.org> - 2017-04-06 13:10 +0200
                Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Thomas Gleixner <tglx@linutronix.de> - 2017-04-06 13:20 +0200
                Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Ingo Molnar <mingo@kernel.org> - 2017-04-07 09:20 +0200
    Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Peter Zijlstra <peterz@infradead.org> - 2017-04-06 11:40 +0200
  Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Peter Zijlstra <peterz@infradead.org> - 2017-04-06 11:40 +0200
    Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2017-04-06 11:50 +0200
      Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Peter Zijlstra <peterz@infradead.org> - 2017-04-06 12:40 +0200
        Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Thomas Gleixner <tglx@linutronix.de> - 2017-04-06 12:50 +0200
          Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Peter Zijlstra <peterz@infradead.org> - 2017-04-06 13:00 +0200
            Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Thomas Gleixner <tglx@linutronix.de> - 2017-04-06 13:10 +0200
              Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Peter Zijlstra <peterz@infradead.org> - 2017-04-06 14:00 +0200
                Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Thomas Gleixner <tglx@linutronix.de> - 2017-04-06 14:00 +0200
                Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU  mask Peter Zijlstra <peterz@infradead.org> - 2017-04-06 14:40 +0200

csiph-web