On 22.07.19 14:18, Jan Beulich wrote:
On 22.07.2019 14:06, Andrew Cooper wrote:
Does reverting back to credit1 make the issue go away? I've never
encountered this on any smt=0 test, but I also don't use credit2 at all.
I'll try to remember trying this out the next time I see it. I can't
see a connection to the used scheduler though, when the message comes
out of __cpu_die(). There must be an excessive delay for the dying
CPU to finally call cpu_exit_clear(). I wonder if the CPU might e.g.
be scrubbing memory at that point. But that shouldn't happen this
early.
The sibling threads shouldn't be inserted into the scheduler in the
first place, and I thought we took deliberate steps to prevent that from
occurring.
I don't think we did, but I agree this may be worthwhile to do if it
wouldn't result in adding ugly special cases somewhere.
Hmm, I wonder if my patch "xen/sched: populate cpupool0 only after all
cpus are up" from my core scheduling series might help?
I already thought of moving it rather to the beginning of the series as
it could go in even without the core scheduling.
Juergen
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
