Messages in this thread | | | Subject | Re: [PATCH v3 03/10] sched/topology: Provide cfs_overload_cpus bitmap | From | Steven Sistare <> | Date | Mon, 26 Nov 2018 14:06:15 -0500 |
| |
On 11/20/2018 7:42 AM, Valentin Schneider wrote: > On 19/11/2018 17:33, Steven Sistare wrote: > [...] >>> >>> Thinking about misfit stealing, we can't use the sd_llc_shared's because >>> on big.LITTLE misfit migrations happen across LLC domains. >>> >>> I was thinking of adding a misfit sparsemask to the root_domain, but >>> then I thought we could do the same thing for cfs_overload_cpus. >>> >>> By doing so we'd have a single source of information for overloaded CPUs, >>> and we could filter that down during idle balance - you mentioned earlier >>> wanting to try stealing at each SD level. This would also let you get >>> rid of [PATCH 02]. >>> >>> The main part of try_steal() could then be written down as something like >>> this: >>> >>> ----->8----- >>> >>> for_each_domain(this_cpu, sd) { >>> span = sched_domain_span(sd) >>> >>> for_each_sparse_wrap(src_cpu, overload_cpus) { >>> if (cpumask_test_cpu(src_cpu, span) && >>> steal_from(dts_rq, dst_rf, &locked, src_cpu)) { >>> stolen = 1; >>> goto out; >>> } >>> } >>> } >>> >>> ------8<----- >>> >>> We could limit the stealing to stop at the highest SD_SHARE_PKG_RESOURCES >>> domain for now so there would be no behavioural change - but we'd >>> factorize the #ifdef SCHED_SMT bit. Furthermore, the door would be open >>> to further stealing. >>> >>> What do you think? >> >> That is not efficient for a multi-level search because at each domain level we >> would (re) iterate over overloaded candidates that do not belong in that level. > > > Mmm I was thinking we could abuse the wrap() and start at > (fls(prev_span) + 1), but we're not guaranteed to have contiguous spans - > the Arm Juno for instance has [0, 3, 4], [1, 2] as MC-level domains, so > that goes down the drain. > > Another thing that has been trotting in my head would be some helper to > create a cpumask from a sparsemask (some sort of sparsemask_span()), > which would let us use the standard mask operators: > > ----->8----- > struct cpumask *overload_span = sparsemask_span(overload_cpus) > > for_each_domain(this_cpu, sd) > for_each_cpu_and(src_cpu, overload_span, sched_domain_span(sd)) > <steal_from here> > -----8>----- > > The cpumask could be part of the sparsemask struct to save us the > allocation, and only updated when calling sparsemask_span().
I thought of providing something like this along with other sparsemask utility functions, but I decided to be minimalist, and let others add more functions if/when they become needed. this_cpu_cpumask_var_ptr(select_idle_mask) is a temporary that could be used as the destination of the conversion.
Also, conversion adds cost, particularly on larger systems. When comparing a cpumask and a sparsemask, it is more efficient to iterate over the smaller set, and test for membership in the larger, such as in try_steal:
for_each_cpu(src_cpu, cpu_smt_mask(dst_cpu)) { if (sparsemask_test_elem(src_cpu, overload_cpus) >> To extend stealing across LLC, I would like to keep the per-LLC sparsemask, >> but add to each SD a list of sparsemask pointers. The list nodes would be >> private, but the sparsemask structs would be shared. Each list would include >> the masks that overlap the SD's members. The list would be a singleton at the >> core and LLC levels (same as the socket level for most processors), and would >> have multiple elements at the NUMA level. > > I see. As for misfit, creating asym_cpucapacity siblings of the sd_llc_*() > functions seems a bit much - there'd be a lot of redundancy for basically > just a single shared sparsemask, which is why I was rambling about moving > things to root_domain. > > Having different locations where sparsemasks are stored is a bit of a > pain which I'd like to avoid, but if it can't be unified I suppose we'll > have to live with it.
I don't follow. A per-LLC sparsemask representing misfits can be allocated with one more line in sd_llc_alloc, and you can steal across LLC using the list I briefly described above.
- Steve
| |