Hi,
lmbench-3.0-a7 has a new useful option to control job
placement. The option #5 (spread) says:
5) Assign each benchmark and attendant processes to
their own processors, except that they will be as far
as possible from each other and other processes
But actually the same CPU number is sorted by
reverse_bits() for CPU numbers 0,2,5,7 as you can see
in the next table
Prev_cpu Next_cpu
0 0
1 4
2 2
3 6
4 1
5 5
6 3
7 7
Furthermore function reverse_bits() does not take
into account CPU physical package id while calculates
as far as possible CPU.
Proposed patch calculates next cpu number on the
basis of files
/sys/devices/system/cpu/cpuNNN/topology/physical_p
ackage_id
if the file is present. To avoid looking into the
file during benchmark run time the array
cpu_other_package[] number is created by
lmbench/scripts/build in the file lib_sched.h at a
time of lmbench install. So it is not need to read
physical_package_id inside measured by benchmark time
interval.
Next algorithm is used for as far as possible
CPU number calculating
do
next_cpu=(next_cpu++)%num_of_cpu;
untile (pack_id [prev_cpu] != pack_id [next_cpu])
If there is no file physical_package_id in the system
or all id’s are the same, next CPU is calculated
using formula
(cpu + num_of_cpus / 2 ) % num_of_cpus
because as far as possible CPU is a diameter opposite
CPU if we consider CPUs set as a ring.
Leonid
patch for far CPU culculating
Logged In: YES
user_id=102874
Originator: NO
There are elements of this patch that I like, and elements that I dislike. I like the way of determining the physical placement of processors. However, I think it should be done at runtime, and not at compile time. The idea is that the benchmarks can run on multiple machines without recompilation. Plus, you can have hot-plug CPUs, so you really cannot depend on compile-time information of this sort.
I will think about this some more and try to put a variant of this patch in place that does everything at runtime rather than compile time.