Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 11 Jul 2023 11:26:11 -0500 | From | David Vernet <> | Subject | Re: [PATCH v2 5/7] sched: Implement shared runqueue in CFS |
| |
On Tue, Jul 11, 2023 at 12:18:32PM +0200, Peter Zijlstra wrote: > On Mon, Jul 10, 2023 at 03:03:40PM -0500, David Vernet wrote: > > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > > index 1451f5aa82ac..3ad437d4ea3d 100644 > > --- a/kernel/sched/core.c > > +++ b/kernel/sched/core.c > > > @@ -9842,6 +9843,7 @@ void __init sched_init_smp(void) > > > > init_sched_rt_class(); > > init_sched_dl_class(); > > + init_sched_fair_class_late(); > > > > sched_smp_initialized = true; > > } > > > @@ -12854,3 +12999,34 @@ __init void init_sched_fair_class(void) > > #endif /* SMP */ > > > > } > > + > > +__init void init_sched_fair_class_late(void) > > +{ > > +#ifdef CONFIG_SMP > > + int i; > > + struct shared_runq *shared_runq; > > + struct rq *rq; > > + struct rq *llc_rq; > > + > > + for_each_possible_cpu(i) { > > + if (per_cpu(sd_llc_id, i) == i) { > > + llc_rq = cpu_rq(i); > > + > > + shared_runq = kzalloc_node(sizeof(struct shared_runq), > > + GFP_KERNEL, cpu_to_node(i)); > > + INIT_LIST_HEAD(&shared_runq->list); > > + spin_lock_init(&shared_runq->lock); > > + llc_rq->cfs.shared_runq = shared_runq; > > + } > > + } > > + > > + for_each_possible_cpu(i) { > > + rq = cpu_rq(i); > > + llc_rq = cpu_rq(per_cpu(sd_llc_id, i)); > > + > > + if (rq == llc_rq) > > + continue; > > + rq->cfs.shared_runq = llc_rq->cfs.shared_runq; > > + } > > +#endif /* SMP */ > > +} > > I don't think this is right; the llc_id thing depends on the online > mask, not on possible mask. So if you boot with a number of CPUs offline > and late bring them online, you're screwy (IIRC this is actually a very > common thing in virt land). > > Additionally, llc_id depends on the sched_domain tree, if someone were > to go create partitions, they can split an LLC and llc_id would split > right along with it. > > I think you need to move this into sched/topology.c and handle hotplug / > domain (re) creation.
Yeah, you're right. This falls apart if we hotplug when we do domain recreation. I'll address this in v3.
> And yes, that's going to be a pain, because you might need to re-hash > existing lists.
Eh, it needs to be done. I played around with this for a bit before sending the v1 RFC code but ended up keeping the series simple because it was RFC, and fixing this is pretty involved. I should have taken care of it regardless before dropping the RFC tag, so glad you pointed it out.
| ![\](/images/icornerr.gif) |