On 25/03/2019 11:53, Dario Faggioli wrote: > On Sat, 2019-03-23 at 14:22 +0100, Juergen Gross wrote: >> On 23/03/2019 03:32, Dario Faggioli wrote: >>> To properly deal with offline CPUs, I think we can change the logic >>> a >>> little, i.e., we initialize the smt_idle mask to all-1 (all CPUs >>> idle), >>> and we also make sure that we set the CPU bit (instead of learing >>> it) >>> in smt_idle, when we remove the CPU from the scheduler. >> >> How does that help? >> >> Only if all siblings are marked as idle in rqd->idle we set any bits >> in rqd->smt_idle (all siblings). >> >> Or did you mean rqd->idle instead? >> > Yep, indeed I was thinking to rqd->idle, sorry for the confusion. :-) > >> This might be problematic in case of runqueue per cpu, though. >> > Mmm... So, my point here is, when a CPU does not belong to a scheduler > (and, in case of Credit2, even when it does not belong to a runqueue) > we "consider" it as being either idle or busy, depending on whether we > set or clear the relevant bit. > > But truth is, we don't have a way to know if it is really idle or not, > so we really shouldn't rely on such info. > > Therefore, we should: > - make sure that we actually don't, or it's a bug (which is the point > of this patch ;-P) > - decide whether to set or clear the bit basing on what's more > convenient (e.g., because it saves some cpumask operation). > > Anyway... > >> Another idea: we could introduce a credit2 pcpu data cpumask pointer >> for replacement of the cpu_sibling_mask. For runqueue per cpu it >> would >> pount to cpumask_of(cpu), for the "normal case" it would point to the >> correct cpu_sibling_mask, and for special cases we could allocate a >> mask if needed. >> > ... I think I am fine with this idea.
Preparing V2 of the patch... Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
