31–40 of 116 posts
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.
I don't understand that level of coding, what i do understand is the great way of debugging. Its all about deduction mr Watson.
Watson was actually Dr. Watson. Which is/was also the name of a debugger in Windows[0]. [0] - https://en.wikipedia.org/wiki/Dr._Watson_(debugger)
I don't understand that level of coding, what i do understand is the great way of debugging. Its all about deduction mr Watson.
Watson was actually Dr. Watson. Which is/was also the name of a debugger in Windows[0]. [0] - https://en.wikipedia.org/wiki/Dr._Watson_(debugger)
wow, just wow. That is a really awesome bug (and like the authors I have issues with trying to sleep when that sort of puzzle is sitting there :-) Still a bit hazy on why they manually flush the cache for a given block of memory (presumably for protecting disclosure?) but I'm also a bit curious how it works if you get the sequence big fetches a cache line, switches to little which fetches a line (half as long and cha…
Handling of the case where big and little both want the same thing in their cache should be dealt with by the usual cache-coherency traffic between the CPUs that ensures they don't disagree about what's in their L1 caches (very handwaved because I don't know the details). The reason for the manual cache operations is because they're generating JITted code -- on ARM to ensure that what you execute is the same thing yo…
I'll admit that I find the question of dissimilar cache line sizes into the same cache intriguing from an architecture point of view. It has me doodling all sorts of questions into my notebook.
I would do nasty, painful things to the designer of such a system.
Properly configured big.LITTLE clusters should be set up so that all CPUs report the same cache line size (which might be smaller than the true cache line size for some of the CPUs), to avoid exactly this kind of problem. The libgcc code assumes the hardware is correctly put together. There is a Linux kernel patchset currently going through review which provides a workaround for this kind of erratum by trapping the C…
Yo Dawg, I heard you like cache invalidation problems! So I put a cache invalidation problem in your cache invalidation problem.
wow, just wow. That is a really awesome bug (and like the authors I have issues with trying to sleep when that sort of puzzle is sitting there :-) Still a bit hazy on why they manually flush the cache for a given block of memory (presumably for protecting disclosure?) but I'm also a bit curious how it works if you get the sequence big fetches a cache line, switches to little which fetches a line (half as long and cha…
Properly configured big.LITTLE clusters should be set up so that all CPUs report the same cache line size (which might be smaller than the true cache line size for some of the CPUs), to avoid exactly this kind of problem. The libgcc code assumes the hardware is correctly put together. There is a Linux kernel patchset currently going through review which provides a workaround for this kind of erratum by trapping the C…
what's the incentive for cpu manufacturer to make effort of building extra cache memory in hardware for bigger cpu in ARM64, if there is no sane way to use it ?