Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A tale of an impossible bug: big.LITTLE and caching

mono-project.com

Post reply on HN
Print view View original

111–116 of 116 posts

Re: A tale of an impossible bug: big.LITTLE and caching

#111

Post by mikeash »

deathanatos wrote: post #77
mikeash wrote: post #59

Earlier quoted context omitted.

It's a great quote, but it's wrong. There are actually two hard things in CS: cache invalidation, naming, and off-by-one errors.

The parent actually appears to have the quote both correct in content and attribution. Supposedly, someone else added the "off by one"[1][2][3]. That seems to be the extent of the Internet's knowledge on the quote, though the Skeptics link notes that there's nothing direct to the supposed originator. This is one of those quotes where I feel there's more than one right answer. I like the addition of "off-by-one", and…

The other one is the original, I just like the "off by one" version better.

I like the addition of "concurrency" too, but I'm not quite sure how to make it flow....

Re: A tale of an impossible bug: big.LITTLE and caching

#112

Post by gcp »

pawadu wrote: post #109
gcp wrote: post #108

Earlier quoted context omitted.

ARM ARM, section B2.2.6 The CTR holds minimum line length values for: - the instruction caches ...this value is the most efficient address stride to use to apply to a sequence of address-based maintenance operations to a range of addresses... The documentation for the CTR_EL0 reg talks about "caches under this processors control" which you could argue don't include other cores, but if you allow migration between core…

I appreciate you digging up the relevant text from the manual, but I don't think you should accuse Samsung of wrongdoing based on such far fetched assumptions. That document does not explicitly forbids this. In addition, take a look at their sample code which indeed reads some cache configuration registers during each call. The same code is found verbatim in the linux kernel, if you now don't trust the ARM engineers…

> far fetched assumptions

I don't think considering how to actually implement the basic operation without a terrible performance penalty is a "far fetched assumption".

> That document does not explicitly forbids this.

Yet it makes it clear software can be written to assume it doesn't happen, which is the same thing.

> In addition, take a look at their sample code which indeed reads some cache configuration registers during each call.

This doesn't prevent the problem at all, it just reduces the window for things to go wrong.

> The same code is found verbatim in the linux kernel, if you now don't trust the ARM engineers :)

I trust the ARM engineers. As I already said, their code is right, Samsung got it wrong. Note that the libgcc code that breaks was ALSO written by ARM.

Re: A tale of an impossible bug: big.LITTLE and caching

#114

Post by caf »

oshepherd wrote: post #101
caf wrote: post #89

Earlier quoted context omitted.

I don't think that helps - the point is that the flush might not be effective if the flushing thread gets scheduled away from the core which has the stale I$ before it manages to fully issue the flush. Or is the flush guaranteed to flush all cores caches? That would be a fairly unusual design.

IC IVAU instructions are broadcast to all cores in the same 'inner shareable domain' (all cores running the same OS instance are in the same inner shareable domain)

That does seem like a good solution to let you do this kind of invalidation in userspace. Thanks.

Re: A tale of an impossible bug: big.LITTLE and caching

#115

Post by Animats »

dfox wrote: post #85
Animats wrote: post #58

"first mass produced AMP architecture" Nope. Remember the Cell? The processor in the Playstation 3? One main CPU with 8 little CPUs and no shared memory, just channels. The Playstation 4 isn't a AMP machine because programming the Cell was so hard.

Cell is essentially distributed memory cluster on single chip, because each SPU has it's own address space and cannot directly access main memory. I'm not sure about what the exact definition of AMP is, but it does not exactly match my feeling of what AMP should be. In this regard Wii seems more like AMP systems with two completely different CPUs (PPC and ARM) sharing what essentially amounts to be same address space…

The real problem with the Cell was that each Cell SPE processor only has 256K of local memory. It has bulk DMA access to main memory, but that's more like I/O. 256K is too small for a video frame, a game level, or much else in a modern game. So everything has to be done on an assembly line basis, where data is pumped into a Cell processor, processed, and pumped out. Great for audio, terrible for everything else. In comparison, the main processor had access to 256MB of RAM.

If they'd had, say, 16MB per processor, it might have worked out. One CPU for collision detection and physics, one for NPC management and AI, etc. But giving each SPE processor only 0.1% of the total memory space was too constraining.

Re: A tale of an impossible bug: big.LITTLE and caching

#116

Post by abysmallyideal »

gcp wrote: post #104
sangnoir wrote: post #98

Earlier quoted context omitted.

> 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.

The 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.

That is a bit far-fetched, as it seems to mostly affect how mono and gcc(?) JIT is designed.
Post reply on HN