4 ms·
Different cacheline sizes for the different cores seems like an absurdly bad idea. One because it opens one up to bugs like these, but also because it makes opt
by anarazel 10y ago
Different cacheline sizes for the different cores seems like an absurdly bad idea. One because it opens one up to bugs like these, but also because it makes optimization a lot harder. I have a hard time believing the savings due to a larger line size are worth it.
- digi_owl 10y agoBest i can tell, the whole thing is designed so that you can go from a a single "little" all the way to two sets of four. Thus each core is designed to be used both independently and in larger configurations.
- gcp 10y agoARM's own designs (A53, A57, A72, A73) all have 64-byte cache line sizes and avoid the problem entirely. The one at fault appears to be Samsung, who designed M1 Mongoose with 128 byte lines and packed it together with A53 cores in their SoC.
- pawadu 10y agoYou could also say that the ARM implementation is not optimal since it uses the same cache size for vastly different designs (different pipeline length and memory access characteristics). Samsung tried to improve performance, I don't think they are at fault at all.
- gcp 10y agoSamsung's design breaks correctly written user-land code. Hence, they're 100% at fault. Going to 128-byte cache lines was fine, but they should have made the lower-power part of the chip match (which in this case they likely couldn't because they licensed that design), or they should have made sure 128-byte lines were reported in all circumstances (which requires a hack similar to the workaround done in the kernel because again they can't make the A53 report 64 bytes).
- sangnoir 10y ago> Samsung's design breaks correctly written user-land code. Hence, they're 100% at fault. This is similar to blaming OS/BIOS manufaturers for Y2K breaking "correctly written code" at the turn of the millenium.The code was incorrect in this instance because it assumed the cache size would be the same for all cores, Samsung simply manufactured a SOC that breaks that faulty assumption.
- gcp 10y agoThe assumption isn't faulty, it's guaranteed to be right. And it has to be, or there's no way to write functional code for ARM.
- abysmallyideal 10y agoThat is a bit far-fetched, as it seems to mostly affect how mono and gcc(?) JIT is designed.
- oshepherd 10y agoThe architecture states that CTR_EL0 reports the _minimum_ ICache line size across all cores. In this system, that would be 64 bytes.
- pawadu 10y agoCan you point me to the manual that does say so? This is all I could find on the subject > [3:0] IminLine Log 2 of the number of words in the smallest cache line of all the Instruction Caches that the processor controls. > This values is: > 0x4 > Smallest Instruction Cache line size is 16 words.
- pawadu 10y ago> Samsung's design breaks correctly written user-land code. Are you sure? From the article, it sounds to me that the real cause of the error is an incorrect assumption made by the GCC people.
- cesarb 10y agoPerhaps a better (and simpler) workaround, then, could be to clamp the reported cache line size to 64 bytes. So even if the Samsung core reports 128-byte cache lines, the code would simply invalidate each line twice, and if it is migrated in the middle of the invalidation loop, it would still work correctly.
- gcp 10y agoThis is exactly the fix used in the kernel, yes. The trickiness and complexity comes from the cache line size probe having to be intercepted.