Differential D23659
x86: Fix scheduler topology assumptions about uniformity Authored by cem on Feb 13 2020, 2:48 AM. Tags None Referenced Files
Subscribers None
Details This could be triggered by taking a 2-socket system and disabling all cores There is no reason we cannot make reasonable scheduling decisions based on Submitted by: Mike Evans (earlier version) Without this change, hitting sched_setup_smp() in sched_ule on a non-uniform
Diff Detail
Event TimelineComment Actions So this looks to me like we made a bad topology and then worked around it by weakening the search. This should still make the leaf topology node for the lone cpu. Otherwise ULE will make bad decisions. Can you show me the boot verbose or sysctl kern.sched.topology_spec from this configuration? Comment Actions Yeah, it seems so.
I don't have the former anymore; the latter I guess we could get with this change to avoid panic. I'd have to ask MikeE, I don't have direct access to this system. If it helps, the machine is a quad-socket with 24 cores (maybe threads) per socket; however, all CPUs on sockets 0, 2, and 3 have been disabled, except for the BSP thread on socket 0. So it's a 25-core non-uniform configuration; the idea is to measure NUMA latency from socket 1 to devices on socket 0. When the BSP's sibling hyperthread is left enabled, the reported panic goes away. Comment Actions Ok, yes, the issue is we never created a leaf for this lone cpu. The problem with this is that ULE will assume all of the other CPUs in the system are in the leaf with the BSP. I haven't reviewed the amd64 code in some time but it probably assumes that a cpu with no neighbors is already in a set above with peers. When you add HTT it has one peer and they share something different than the existing set. It should be fixed there. |