With these patches, a kernel build on a 104-cpu machine took around 75%
less wall time and 85% less system time. Note that there is a difference
in v5.2-rt compared to v5.0-rt. The performance with these patches is
similar in both cases, but without these patches v5.2-rt is substantially
slower. In v5.0-rt with a previous version of these patches, lazy
migrate disable reduced kernel build time by around 15-20% wall and
70-75% system.
Scott Wood (8):
sched: migrate_enable: Use sleeping_lock to indicate involuntary sleep
sched: __set_cpus_allowed_ptr: Check cpus_mask, not cpus_ptr
sched: Remove dead __migrate_disabled() check
sched: migrate disable: Protect cpus_ptr with lock
sched/deadline: Reclaim cpuset bandwidth in .migrate_task_rq()
sched: migrate_enable: Set state to TASK_RUNNING
sched: migrate_enable: Use select_fallback_rq()
sched: Lazy migrate_disable processing
include/linux/cpu.h | 4 -
include/linux/sched.h | 15 ++--
init/init_task.c | 4 +
kernel/cpu.c | 97 ++++++++---------------
kernel/rcu/tree_plugin.h | 2 +-
kernel/sched/core.c | 200 +++++++++++++++++++----------------------------
kernel/sched/deadline.c | 67 ++++++++--------
kernel/sched/sched.h | 4 +
lib/smp_processor_id.c | 3 +
9 files changed, 166 insertions(+), 230 deletions(-)
--
1.8.3.1
Various places assume that cpus_ptr is protected by rq/pi locks,
so don't change it before grabbing those locks.
Signed-off-by: Scott Wood <[email protected]>
---
kernel/sched/core.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 99a3cfccf4d3..38a9a9df5638 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7283,9 +7283,8 @@ void dump_cpu_task(int cpu)
struct rq *rq;
struct rq_flags rf;
- p->cpus_ptr = cpumask_of(smp_processor_id());
-
rq = task_rq_lock(p, &rf);
+ p->cpus_ptr = cpumask_of(smp_processor_id());
update_nr_migratory(p, -1);
p->nr_cpus_allowed = 1;
task_rq_unlock(rq, p, &rf);
@@ -7297,9 +7296,8 @@ void dump_cpu_task(int cpu)
struct rq *rq;
struct rq_flags rf;
- p->cpus_ptr = &p->cpus_mask;
-
rq = task_rq_lock(p, &rf);
+ p->cpus_ptr = &p->cpus_mask;
p->nr_cpus_allowed = cpumask_weight(&p->cpus_mask);
update_nr_migratory(p, 1);
task_rq_unlock(rq, p, &rf);
--
1.8.3.1
On 2019-07-27 00:56:34 [-0500], Scott Wood wrote:
> Various places assume that cpus_ptr is protected by rq/pi locks,
> so don't change it before grabbing those locks.
>
> Signed-off-by: Scott Wood <[email protected]>
I applied now everything until here and you can take a look at
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/log/?h=linux-5.2.y-rt-RC
If there are no objections then I would make this a -rt9 and then go
further.
Sebastian
On Thu, 2019-09-26 at 18:39 +0200, Sebastian Andrzej Siewior wrote:
> On 2019-07-27 00:56:34 [-0500], Scott Wood wrote:
> > Various places assume that cpus_ptr is protected by rq/pi locks,
> > so don't change it before grabbing those locks.
> >
> > Signed-off-by: Scott Wood <[email protected]>
>
> I applied now everything until here and you can take a look at
>
> https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/log/?h=linux-5.2.y-rt-RC
>
> If there are no objections then I would make this a -rt9 and then go
> further.
>
> Sebastian
Looks good, thanks!
-Scott
On 2019-09-26 11:52:42 [-0500], Scott Wood wrote:
> Looks good, thanks!
Thanks, just released.
Moving forward. It would be nice to have some DL-dev feedback on DL
patch. For the remaining once, could please throw Steven's
stress-test-hostplug-cpu-script? If that one does not complain I don't
see a reason why not apply the patches (since they improve performance
and do not break anything while doing so).
> -Scott
Sebastian
On Fri, 2019-09-27 at 14:19 +0200, Sebastian Andrzej Siewior wrote:
> On 2019-09-26 11:52:42 [-0500], Scott Wood wrote:
> > Looks good, thanks!
>
> Thanks, just released.
> Moving forward. It would be nice to have some DL-dev feedback on DL
> patch. For the remaining once, could please throw Steven's
> stress-test-hostplug-cpu-script? If that one does not complain I don't
> see a reason why not apply the patches (since they improve performance
> and do not break anything while doing so).
I'd been using a quick-and-dirty script that does something similar, and ran
it along with rcutorture, a kernel build, and something that randomly
changes affinities -- though with these loads I have to ignore occasional
RCU forward progress complaints that Paul said were expected with this
version of the RCU code, XFS warnings that happen even on unmodified non-RT,
and sometimes a transitory netdev timeout that is not that surprising given
the heavy load and affinity stress (I get it without these patches as well,
though it takes longer).
I just ran Steven's script (both alone and with the other stuff above) and
saw no difference.
-Scott