summaryrefslogtreecommitdiff
path: root/init
diff options
context:
space:
mode:
authorSebastian Andrzej Siewior <bigeasy@linutronix.de>2017-04-04 12:50:16 +0200
committerSebastian Andrzej Siewior <bigeasy@linutronix.de>2018-10-29 18:19:20 +0100
commit573a89de364ae29438698492cd3ef63cb66c2eec (patch)
tree7814334e71890172a11b4b5961a8ffc5155b4fd0 /init
parent2d3fba69f65008269d33a07926bf8e5073770aaa (diff)
kernel: sched: Provide a pointer to the valid CPU mask
In commit 4b53a3412d66 ("sched/core: Remove the tsk_nr_cpus_allowed() wrapper") the tsk_nr_cpus_allowed() wrapper was removed. There was not much difference in !RT but in RT we used this to implement migrate_disable(). Within a migrate_disable() section the CPU mask is restricted to single CPU while the "normal" CPU mask remains untouched. As an alternative implementation Ingo suggested to use struct task_struct { const cpumask_t *cpus_ptr; cpumask_t cpus_mask; }; with t->cpus_allowed_ptr = &t->cpus_allowed; In -RT we then can switch the cpus_ptr to t->cpus_allowed_ptr = &cpumask_of(task_cpu(p)); in a migration disabled region. The rules are simple: - Code that 'uses' ->cpus_allowed would use the pointer. - Code that 'modifies' ->cpus_allowed would use the direct mask. While converting the existing users I tried to stick with the rules above however… well mostly CPUFREQ tries to temporary switch the CPU mask to do something on a certain CPU and then switches the mask back it its original value. So in theory `cpus_ptr' could or should be used. However if this is invoked in a migration disabled region (which is not the case because it would require something like preempt_disable() and set_cpus_allowed_ptr() might sleep so it can't be) then the "restore" part would restore the wrong mask. So it only looks strange and I go for the pointer… Some drivers copy the cpumask without cpumask_copy() and others use cpumask_copy but without alloc_cpumask_var(). I did not fix those as part of this, could do this as a follow up… So is this the way we want it? Is the usage of `cpus_ptr' vs `cpus_mask' for the set + restore part (see cpufreq users) what we want? At some point it looks like they should use a different interface for their doing. I am not sure why switching to certain CPU is important but maybe it could be done via a workqueue from the CPUFREQ core (so we have a comment desribing why are doing this and a get_online_cpus() to ensure that the CPU does not go offline too early). Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Mike Galbraith <efault@gmx.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Diffstat (limited to 'init')
-rw-r--r--init/init_task.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/init/init_task.c b/init/init_task.c
index 5aebe3be4d7c..0b49b9cf5571 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -71,7 +71,8 @@ struct task_struct init_task
.static_prio = MAX_PRIO - 20,
.normal_prio = MAX_PRIO - 20,
.policy = SCHED_NORMAL,
- .cpus_allowed = CPU_MASK_ALL,
+ .cpus_ptr = &init_task.cpus_mask,
+ .cpus_mask = CPU_MASK_ALL,
.nr_cpus_allowed= NR_CPUS,
.mm = NULL,
.active_mm = &init_mm,