Hi John,

As always, it depends :)

In my previous job, We had a system that processing orders in 100us. Here
thread affinity and core isolation were mandatory to achieve the SLA. The
difference measured was from 2x to 4x.
But not all systems need this setting/tuning. if you are accessing a lot of
memory and it does not fit most of the time in CPU caches I don't think
this will make a big difference like we had.
So measure, and see what are the figures. As Gil pointed, it's relatively
easy to setup a test by pinning by hand your critical threads with taskset
for example.

Regards


On Sun, Apr 8, 2018 at 2:51 PM, John Hening <gocio...@gmail.com> wrote:

> Hello,
>
> 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.
>
> *Intro*:
> 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.
>
> *Question*:
> 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.
>

-- 
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