[pantalaimon]

Catching the bad instruction fault on the E-cores and only scheduling the thread on the P-cores would be something that could be added to Linux (there were already third party patches towards that goal) if Intel had not disable the feature entirely.

[jeffbee]

But it's not really compatible with the GCC IFUNC scheme ... PTL entries will be permanently remapped to the most appropriate code on the CPU where the function is first called, and never thereafter remapped. So you end up with a coin toss whether you get the optimized function or not.

Personally I don't find the e-cores on my alder lake CPU to be of any value. They're more of a hazard than a benefit.

[janwas]

Fair point about ifunc, but we're using our own table of function pointers, which can be invalidated/re-initialized. Someone also mentioned that the OS could catch SIGILL.. indeed seems doable to then reset thread affinity to the P cores?

[saagarjha]

Presumably the AVX-512 code is something on your hot path, so I’m not sure waiting for a signal to reschedule the work is something you would want.

[heavenlyblue]

You reschedule it only once so it doesn’t matter

[saagarjha]

I don’t see how? Once your quantum is up the thread gets put back into the scheduling pool and you have to do this all over again…

[boardwaalk]

Couldn’t there be some flag on the thread that marks it as “P-core only”? Doesn’t seem hard. I don’t known Linux scheduler internals though.

[pantalaimon]

Threads already have an affinity bit mask where you can select which cores they can be scheduled on.

https://man7.org/linux/man-pages/man2/sched_setaffinity.2.ht...

[saagarjha]

Right but then you’d just have all processes with that flag all the time.

[pantalaimon]

Only if glibc decides to use AVX512 for memset and such. I’m not sure if that makes sense to begin with, but it could also not do that if it detects a heterogeneous CPU.

[heavenlyblue]

You don’t have to schedule your thread on another core at all