From: Thomas Gleixner <tglx@linutronix.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Mike Galbraith <efault@gmx.de>, Ingo Molnar <mingo@elte.hu>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>
Subject: Re: [RFC PATCH] kernel: sched: Provide a pointer to the valid CPU mask
Date: Thu, 6 Apr 2017 12:36:47 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1704061052370.1716@nanos> (raw)
In-Reply-To: <20170406080139.GA22069@gmail.com>
On Thu, 6 Apr 2017, Ingo Molnar wrote:
> Sorry if this is a back and forth - I was somehow convinced that we do need to
> frob the cpus_allowed mask to get this functionality - but in hindsight I think
> the counter should be enough.
>
> I.e. just have a counter and these two APIs:
>
> static inline void migrate_disable(void)
> {
> current->migration_disabled++;
> }
>
> ...
>
> static inline void migrate_enable(void)
> {
> current->migration_disabled--;
> }
>
> ... and make sure the scheduler migration code plus the CPU hotplug code considers
> the counter.
We tried that some time ago, but there are a lot of places in the scheduler
which just rely on the cpus_allowed_mask, so we have to chase all of them
and make sure that new users do not ignore that counter. That's why we
chose the cpus_allowed_mask approach. And I still think that's the proper
thing to do.
Also this still requires magic in the context switch where we need to
transport that information to the CPU, so it can't go away.
CPU hotplug has other issues. If migration is disabled, then blocking out
the hotplug code is probably easy to do, but you need to undo the blocking
when the CPU is not longer pinned, i.e. if the last task enabled migration
again.
To make that all less horrible, we need to fix the stupid nested usage of
get_online_cpus() first. That'd allow us to convert the hotplug locking
into a percpu_rwsem, which is desired anyway as it makes get_online_cpus()
cheap.
So then the migration stuff becomes:
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++;
}
}
void migrate_enable(void)
{
if (in_atomic() || irqs_disabled())
return;
if (current->migration_disabled == 1) {
preempt_disable();
current->migration_disabled--;
percpu_up_read_preempt_enable(hotplug_rwsem);
} else {
current->migration_disabled--;
}
}
That want's to have some debug extras: see the current RT version of it.
Coming back to the cpus_allowed mask.
Most of the cpus_allowed usage outside of the scheduler is broken and we
really should clean that up now and then restrict access to cpus_allowed.
The easy ones (and the majority) are those:
cpumask_copy(saved_mask, ¤t->cpus_allowed);
set_cpus_allowed_ptr(current, cpumask_of(XXX));
do_something();
set_cpus_allowed_ptr(current, saved_mask);
That code is not at all protected against user space changing affinity or
cpus going down. We better do that now before doing anything about
cpus_allowed in the core code.
Thanks,
tglx
next prev parent reply other threads:[~2017-04-06 10:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-04 18:42 Sebastian Andrzej Siewior
2017-04-05 7:39 ` Ingo Molnar
2017-04-05 8:37 ` Sebastian Andrzej Siewior
2017-04-06 6:16 ` Ingo Molnar
2017-04-06 7:38 ` Sebastian Andrzej Siewior
2017-04-06 8:01 ` Ingo Molnar
2017-04-06 9:25 ` Sebastian Andrzej Siewior
2017-04-06 9:46 ` Peter Zijlstra
2017-04-06 10:58 ` Thomas Gleixner
2017-04-06 11:41 ` Peter Zijlstra
2017-04-06 9:35 ` Peter Zijlstra
2017-04-06 9:42 ` Peter Zijlstra
2017-04-06 10:36 ` Thomas Gleixner [this message]
2017-04-06 11:02 ` Ingo Molnar
2017-04-06 11:10 ` Thomas Gleixner
2017-04-07 7:13 ` Ingo Molnar
2017-04-06 9:34 ` Peter Zijlstra
2017-04-06 9:32 ` Peter Zijlstra
2017-04-06 9:46 ` Sebastian Andrzej Siewior
2017-04-06 10:35 ` Peter Zijlstra
2017-04-06 10:47 ` Thomas Gleixner
2017-04-06 10:57 ` Peter Zijlstra
2017-04-06 11:03 ` Thomas Gleixner
2017-04-06 11:50 ` Peter Zijlstra
2017-04-06 11:56 ` Thomas Gleixner
2017-04-06 12:31 ` Peter Zijlstra
2017-04-11 1:38 ` [lkp-robot] [kernel] c1f943ee40: kernel_BUG_at_kernel/smpboot.c kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1704061052370.1716@nanos \
--to=tglx@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®