Daniel B (fejenagy.delete@this.gmail.com) on September 13, 2021 1:57 pm wrote:
> David Hess (davidwhess.delete@this.gmail.com) on September 13, 2021 1:00 pm wrote:
> >
> > Is there any reason not to expect applications to lie? Of course every
> > thread needs to operate on the fastest available core. Ask them.
> >
> > Alternatively why would developers spend time to distinguish which threads should operate on which cores
> > when the result can only make the perceived performance worse? And why risk getting it wrong?
>
> I have no answer to this. Even with good intentions, I don't see how it is possible to know which application
> should run where at any given time without deep performance analysis and an understanding of what the target
> QoS is. I tried a quick Google search, but not much comes up. Qualcomm says they support affinity settings,
> but in the end it all depends on the scheduler. Nothing on Apple iOS so far. Some developers asked the
> question of pinning threads to specific cores but so far the answer seems to be nope. I suspect (most)
> applications do not set this and it is all magic happening in the scheduler black box.

I read a story from an developer earlier today who had problems with a critical thread in their application getting stuck on a slow core, but by the time the scheduler boosted it, it was too late and the thread was finished, but late. By the time the critical thread was executing again, it was stuck on a slow core again and the cycle repeated. The result was unacceptable jitter in the user interface. The solution ended up being to create a do nothing task to take the place of the critical thread when it was not executing to keep the core operating at full speed which is hardly ideal, but they figured out something later.

I have seen pinning threads to specific cores more than double performance by not having to reload cache. In the real time embedded world, addresses might be pinned into the cache.