On May31, 2012, at 02:26 , Sergey Koposov wrote:
> On Thu, 31 May 2012, Florian Pflug wrote:
>> Wait, so performance *increased* by spreading the backends out over as many dies as possible, not by using as few as
possible?That'd be exactly the opposite of what I'd have expected. (I'm assuming that cores on one die have ascending
idson linux. If you could post the contents of /proc/cpuinfo, we could verify that)
>
> Yes, you are correct. And I also can confirm that the cpus in the cpuinfo are ordered by "physical id" e.g. they go
like
> 0 0 0 0 0 0 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3
>
> I did a specific test with just 6 threads (== number of cores per cpu)
> and ran it on a single phys cpu, it took ~ 12 seconds for each thread,
> and when I tried to spread it across 4 cpus it took 7-9 seconds per thread. But all these numbers are anyway
significantlybetter then when I didn't use taskset.
Hm. The only resource that is shared between different cores on a die is usually the last cache level (L2 or L3). So by
spreadingbackends out over more cores, you're increasing the total cache size. Maybe that could explain the behavior
you'reseeing.
> Which probably means without it the processes were jumping from core to core ? …
Seems so. I completely fail to understand why they would, though. Since you've got far fewer runnable processes than
cores,why would the kernel ever see a reason to migrate a process from one core to another? I think that you can query
thecore that a process is running one from one of the files in /proc/<pid>. You could try gathering samples ever 50 ms
orso during the test run - maybe that could shed some additional light on this.
best regards,
Florian Pflug