“Reasonable people adapt themselves to the world. Unreasonable people attempt to adapt the world to themselves. All progress, therefore, depends on unreasonable people.”― George Bernard Shaw <https://www.goodreads.com/author/show/5217.George_Bernard_Shaw> To your question tho: there are plenty of tools available in Linux today to control how cores are used across processes. E.g. between numactl, cpusets, tasksets, and isolcpus, you can shape the way the scheduler chooses which cores are used by which processes and thread pretty well.
On Sunday, April 8, 2018 at 5:51:52 AM UTC-7, John Hening 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.
