On 05/06/15 16:44, Dmitry Olshansky wrote:
* You seem to assume the same. Fine assumption given that OS usually
tries to keep the same cores working on the same threads, for the
similar reasons I believe.
I see that people already raised the point that the OS does allow you to
pin a thread to specific cores, so lets skip repeating that.
AFAIK, the kernel tries to keep threads running on the same core they
did before is because moving them requires so much locking, synchronous
assembly instructions and barriers, resulting in huge costs for
migrating threads between cores.
Which turns out to be relevant to this discussion, because that will,
likely, also be required in order to move fibers between threads.
A while back, a friend and myself ran an (incomplete) research project
where we tried reverting to the long discarded "one thread per socket"
model. It actually performed really well (much much better than the
"common wisdom" would have it perform), provided you did two things:
1. Use a thread pool. Do not actually spawn a new thread each time a new
incoming connection arrives
and
2. pin that thread to a core, don't let it migrate
Since we are talking about several tens of thousands of threads, each
random fluctuation in the load resulted in the kernel's scheduler
wishing to migrate them, resulting in losing thousands of percent worth
of performance. Once we locked the threads into place, we were, more or
less, on par with micro-threading in terms of overall performance the
server could take.
Shachar
