Re: [patch] sched-2.5.59-A2

["Martin J. Bligh" <mbligh@aracnet.com>]

>> > I think the large PPC64 boxes have multilevel NUMA as well - two real
>> > phys cores on one die, sharing some cache (L2 but not L1? Anton?). And
>> > SGI have multilevel nodes too I think ... so we'll still need multilevel
>> > NUMA at some point ... but maybe not right now.
>> 
>> Intel's HT is the cleanest case: pure logical cores, which clearly need
>> special handling. Whether the other SMT solutions want to be handled via
>> the logical-cores code or via another level of NUMA-balancing code,
>> depends on benchmarking results i suspect. It will be one more flexibility
>> that system maintainers will have, it's all set up via the
>> sched_map_runqueue(cpu1, cpu2) boot-time call that 'merges' a CPU's
>> runqueue into another CPU's runqueue. It's basically the 0th level of
>> balancing, which will be fundamentally different. The other levels of
>> balancing are (or should be) similar to each other - only differing in
>> weight of balancing, not differing in the actual algorithm.
> 
> I have included a very rough patch to do ht-numa topology.  I requires to 
> manually define CONFIG_NUMA and CONFIG_NUMA_SCHED.  It also uses num_cpunodes 
> instead of numnodes and defines MAX_NUM_NODES to 8 if CONFIG_NUMA is defined.  

Whilst it's fine for benchmarking, I think this kind of overlap is a 
very bad idea long-term - the confusion introduced is just asking for
trouble. And think what's going to happen when you mix HT and NUMA.
If we're going to use this for HT, it needs abstracting out.

M.