I've read about thread affinity and I see that it is popular in 
high-performance-libraries (for example 
https://github.com/OpenHFT/Java-Thread-Affinity). Ok, jugglery a thread 
between cores has impact (generally) on performance so it is reasonable to 
bind a specific thread to a specific core. 

It is obvious that the best idea to make it possible that any process will 
be an owner of core [let's call it X] (in multi-core CPU). I mean that main 
thread in a process will be one and only thread executed on core X. So, 
there is no problem with context-switching and cache flushing [with expect 
system calls]. 
I know that it requires a special implementation of scheduler in kernel, so 
it requires a modification of [Linux] kernel. I know that it is not so easy 
and so on.

But, we know that we have systems that need a high performance. So, it 
could be a solution with context-switching once and at all. So, why there 
is no a such solution? My suspicions are:

* it is pointless, the bottleneck is elsewhere [However, it is meaningful 
to get thread-affinity]
* it is too hard and there is too risky to make it not correctly
* there is no need
* forking own linux kernel doesn't sound like a good idea.

You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to