"Maciej W. Rozycki" wrote: > Well, I certainly understand what you mean, from the beginning, actually, > but I still can't see why this would happen for a real implementation. > When a cache miss happens an instruction word is read directly from the > main memory to the pipeline and a cache fill happens "accidentally". > > What you describe, would require a CPU to query a cache status somehow > during a fill (what if another fill is in progress? -- a cache controller > may perform a fill of additional lines itself as it happens in certain > implementations) and then issue a second read when the fill completes. > That looks weird to me -- why would you design it this way? > A cache is filled in cachline units. There is a possibility to fill only part of cacheline in one cache and to store the rest of data in another cache on the switch. Both caches will set the valid bit on this cacheline, but only part of cacheline is valid. In the worst cache, this operation may load instructions that will be reused later, for example, part of the main loop of the cache invalidation (sic!) routine. Unfortunately, the behaviour depends on whether miss occurs, what instructions are loaded, how they are aligned, and so on. It means, if you get crash on this kernel version, you won't get a crash on another. If you add debug routines, everything is OK. Other black magic tricks are also here. (As you may guess, I explain my real experience here. :-). Analyzer doesn't help, bus transactions look good.) In order to avoid this, CPU shall either perform the check again or freeze everything on the cache swap operation. The latter doesn't look real. Anyway, it's a lot of additional unnatural logic. So, the requirement to run swapping operation uncached looks reasonable. Regards, Gleb.
