Hi,

Björn Ragnar Björnsson (bjorn.ragnar.delete@this.gmail.com) on May 20, 2022 5:54 pm wrote:
> Mark (nospamplease.delete@this.nothereorthere.com) on May 20, 2022 12:15 pm wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on May 20, 2022 11:32 am wrote:
> > > Brendan (btrotter.delete@this.gmail.com) on May 20, 2022 4:06 am wrote:
> > > >
> > > > To me, supporting dissimilar CPUs (for both "different ISA" and "same ISA with different instruction
> > > > timings") is an interesting engineering challenge [...]
> > >
> > > That's an odd way to spell "stupid and pointless".
> > >
> > > We already know what the problem is. Intel already did the "expose that cores
> > > are different" thing in their desktop/laptop chips. It was an abject and fundamental
> > > failure that is basically unfixable, and Intel already disabled it.
> > >
> > > So no, it's not an "engineering challenge". It was a broken product. It's the
> > > same kind of "engineering challenge" that Itanium was. Just give it up.
> > >
> > > Linus
> >
> > Impossible or merely painful?
> >
> > Catch the unimplemented instruction.
> > Tag the process as fat core only.
> > Reschedule and restart the instruction
>
> On the surface it looks to be solvable. But it isn't really. As someone pointed else pointed
> out you would end up with everything running on fat cores because of libraries ...

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.

Of course it'd be easy to have some/most/all libraries compiled for the common subset too; and easy to emulate unsupported instructions in software instead of migrating (until you know there's enough to warrant migration and P cores don't have more important load).

> Couldn't you just continue with library architecture detection? Well how?

Couldn't you just have 2 virtual address spaces for each process; where one is dynamically linked to P core versions of libraries and the other is dynamically linked to E core versions of libraries; so that when a thread is migrated to a different CPU type the kernel also switches the virtual address space? There'd be minor issues (kernel would need to detect when a thread is currently running library code and refuse to migrate; data would have to be compatible between both versions of a library; compiler would need to auto-generate a wrapper if anything takes a library function pointer like "pointer = &memcpy()"; would have major issues for self-modifying/self-generating programs) but it'd be good enough for almost everything with some compiler support.

> From the core
> a process starts on? That's going to go off the rails fast.

Just slap some "I need these CPU features" flags in the executable file's header.

> So, are you going to do statistics
> in the kernel to move processes around, even after the paths through the librarie's have
> been selected (and the exotic opcodes are gone, or live as the case may be)?

Sure, why not. It's hardly significant when you're already doing most of it anyway (power management, Intel's Thread Director, etc).

> No, the complexity of supporting this is unsupportable. Not unsupportable in the "technical
> possibility" sense, but unsupportable in the real world. It's too much of a burden
> on software development/support to be possible in any meaningly gainful sense. It's
> never going to realize any useful gains for a measurable amount of users.
>
> It's a total mess, that's what it is. Par for the course: Linus is right. Does that surprise
> anyone here :) Just forget Intel's brief interlude with mixed ISA cores ever happened.

Intel's interlude with "same ISA, different performance characteristics" is probably going to last for 20+ years and isn't fundamentally different to ARM's "big.LITTLE" that's existed for 10 years already. Supporting (or optimizing for) "same ISA, different performance characteristics" properly gets you almost all of the way to supporting "different ISA".

- Brendan