Hi Bertrand, On Sat, Mar 27, 2021 at 10:11:45PM +0000, Bertrand Jacquin wrote: > Hi Willy, > > > Another discussion started around an easier support for some modern > > platforms. In issue #1194, Ashley Penney was caught running on AWS's ARM > > instances with the default ARM target optimizations. For having run some > > tests on these machines, I can't say enough how great they are, but I > > also know that in order to unlock their power when dealing with 16 cores > > or more, it's mandatory to use their modern locking extensions. Worse, > > the default ones do not scale at all and easily maintain deadlocks until > > the watchdog gets rid of the situation. I can trivially add a new CPU > > option in the makefile, there are already a few preset, it's easy. But > > the question is more how this could flow back into distro packages if > > possible at all, considering that such code will not run on legacy > > platforms (e.g. RPi). The difficulty here is that it's not about > > optimization anymore but rather choose from "crashes all the time" and > > "works amazingly fast". Another option could be for distros to limit > > the number of threads on such platforms to 4 to cover legacy devices > > well and prevent the degradation from happening on larger systems. But > > this will definitely require that users rebuild themselves to use larger > > platforms. In my opinion it is exactly the same problem we've seen a long > > time ago with x86 and cmov/mmx/sse/avx in that these are all extensions > > used at the lowest compiler level, so I'm sure there's a clean way to > > deal with this but I'm not qualified to say how. All ideas welcome! > > Correct me if I'm wrong, I do believe this is a perfect example for > using new glibc feature hwcaps which allow a given object to be > compiled with multiple level of optimization and let the loader select > the more appropriate elf tree at runtime. I am no expert about nor have > played with it, however the issue you are mentioning here does remind me > https://sourceware.org/pipermail/libc-alpha/2020-June/115250.html. Note > it does appear only x86_64, powerpc and s390 are supported at this stage.
Here it's different, it's not even in glibc, it's even lower level, it's directly the instruction set used by the compiler. Willy
