Re: [Xen-devel] [PATCH] xen/sched: fix credit2 smt idle handling

[Dario Faggioli <dfaggioli@xxxxxxxx>]

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.

Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel