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:
> > Daniel B (fejenagy.delete@this.gmail.com) on September 13, 2021 5:20 am wrote:
> > >
> > > Either the scheduler needs to learn the application behaviour
> > > or the application should come tagged, but then the ISV
> > > is expected to understand hardware and system energy
> > > efficiency, which they don't.
> >
> > 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.

Here's the Apple API's:
https://developer.apple.com/library/archive/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/PrioritizeWorkAtTheTaskLevel.html

Unfortunately the deadline scheduling stuff (the concept you need is "Work Interval Object") like so much produced by Apple (and MS and Google...) these days is some combination of terribly documented and half-way public half-way private.
I only see one public API that documents it (for manipulating audio) but the generic idea can be read about here:
https://opensource.apple.com/source/xnu/xnu-4570.41.2/bsd/sys/work_interval.h.auto.html

Many of these concepts I mention are more Darwin than iOS/macOS concepts; the expectation, for better or worse, seems to be that either you use them at the Darwin level (with all the fun that implies in terms of reading header files and man pages to figure out how it all works) or you use the higher level AppleOS primitives, and just accept what they give you in terms of scheduling.

The basic Apple patent describing how to use much of the Thread Director equivalent info is here:
https://patents.google.com/patent/US20170357302A1/en

That's the easy one! The much more complicated one is a year later, here:
https://patents.google.com/patent/US10884811B2
with subsidiary patents like
https://patents.google.com/patent/US20180293102A1/en

These describe how the OS uses the low level HW info, the API and OS-internal concepts it uses, and how to deal with the really big problem (the one you are all ignoring) -- optimal clustering of threads into a thread scheduling group given the constraint (I think this is the governing concern) that all items in a CPU cluster (cores and L2) have to run at the same frequency.
Honestly I can only pick out big ideas in the AMP Scheduler patent; I don't know enough about OS internals to really understand it, but others might learn from it.