On Fri, Aug 31, 2018 at 04:56:18PM +0530, Srikar Dronamraju wrote:
> This was the same in my previous posting too. Before the topology update
> happened, all the cpus would be in SMT, DIE. The topology updates can be
> disabled using a kernel parameter topology_updates=off. Its documented under
> h
* Peter Zijlstra [2018-08-31 12:41:15]:
> On Fri, Aug 31, 2018 at 03:22:48AM -0700, Srikar Dronamraju wrote:
>
> > At boot: Before topology update.
>
> How does that work; you do SMP bringup _before_ you know the topology !?
>
If you look at the other mail that I sent, the system boots to its
On Fri, Aug 31, 2018 at 03:22:48AM -0700, Srikar Dronamraju wrote:
> At boot: Before topology update.
How does that work; you do SMP bringup _before_ you know the topology !?
> After topology update.
>
> For CPU 0
> domain-0: span=0-7 level=SMT
> groups: 0:{ span=0 }, 1:{ span=1 }, 2:{ span=2
* Peter Zijlstra [2018-08-29 10:43:48]:
> On Fri, Aug 10, 2018 at 09:45:33AM -0700, Srikar Dronamraju wrote:
>
> >
> > CPU302 attaching NULL sched-domain.
> > CPU303 attaching NULL sched-domain.
> > BUG: arch topology borken
> > the DIE domain not a subset of the NODE domain
>
> ^
On Wed, Aug 29, 2018 at 10:43:48AM +0200, Peter Zijlstra wrote:
> DIE(j) should be:
>
> cpu_cpu_mask(j) := cpumask_of_node(cpu_to_node(j))
FWIW, I was expecting that to be topology_core_cpumask(), so I'm a
little confused myself just now.
> and NODE(j) should be:
>
> \Union_k cpumas
On Fri, Aug 10, 2018 at 09:45:33AM -0700, Srikar Dronamraju wrote:
> available: 4 nodes (0-3)
> node 0 cpus: 0 1 2 3 4 5 6 7 32 33 34 35 36 37 38 39 64 65 66 67 68 69 70 71
> 96 97 98 99 100 101 102 103 128 129 130 131 132 133 134 135 160 161 162 163
> 164 165 166 167 192 193 194 195 196 197 198
* Peter Zijlstra [2018-08-08 09:58:41]:
> On Wed, Aug 08, 2018 at 12:39:31PM +0530, Srikar Dronamraju wrote:
> > With Commit 051f3ca02e46 ("sched/topology: Introduce NUMA identity node
> > sched domain") scheduler introduces an extra numa level. However that
> > leads to
> >
> > - numa topology
