Doug S (foo.delete@this.bar.bar) on May 21, 2022 12:33 pm wrote:
> anon2 (anon.delete@this.anon.com) on May 21, 2022 1:45 am wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on May 21, 2022 12:06 am wrote:
> > > Brendan (btrotter.delete@this.gmail.com) on May 20, 2022 8:42 pm wrote:
> > > >
> > > > Just because a thread got migrated to a P core doesn't mean it has to stay there - you could migrate
> > > > a thread back to the E core for a while (until it uses the library again) if you want.
> > >
> > > That's the "hey, this can be fixed" thing.
> > >
> > > But the unfixable thing is much more fundamental: 'cpuid' is suddenly not reliable or meaningful.
> > >
> > > Basically, what does 'cpuid' mean?
> > >
> > > Does it mean "what are the capabilities of the CPU I happen to be running on right now"? But
> > > then it's useless in any system where the load can be migrated to another CPU at any time.
> > >
> > > Or does 'cpuid' mean "Ok, I now give you a set of capabilities that I guarantee"? So now any
> > > process that has ever run 'cpuid' will be tied to a code that matches what it was told?
> >
> > Have all cores report AVX-512 is available even the small cores. When a small core tries
> > to execute an AVX-512 instruction it will trap and the OS can move it to a big core
> > then resume it. They don't have to be stuck there, you can have heuristics (time interval,
> > or look at AVX-512 activity) to allow it to move back to a small core.
>
>
> Did you miss his subsequent prebuttal to that idea?

No, he didn't address it. This idea makes cpuid reliable and meaningful. Linus was just talking about reporting one way or the other, not moving tasks as features are needed.

>
>
> > > If you claim you do AVX512, then all processes end up getting pinned to
> > > big cores just because some random library goes "oh, then I'll use it".
>
>
> In another thread dmcq suggests that strlen() not only could but should be implemented with inline SVE2
> code had Apple included it on M1 and thus made it a standard feature of all Apple Silicon Macs.
>
> The possibility of supporting SVE2 on big cores only would be out the window in
> such a case. Even if your own code doesn't call strlen() directly, for every library
> call you make the chance your code uses strlen() quickly approaches 100%.
>
> It only takes one "clever" programmer deciding to utilize AVX-512 in libc or some GUI library
> everyone needs for it to become a limitation on how much code can run on cores that lack it.
>

They could also implement it in some other stupid way and slow everybody down as well.

Heterogeneous cores need more tuning than homo for optimal efficiency. Even if they expose exactly the same ISA they still do.