I feel like focusing on the kernel side misses CPU level issues.
Is there any known upper bound on, say, how long a memory access instruction takes on x86?
Is there any known upper bound on, say, how long a memory access instruction takes on x86?
But for things that really matter, I've tested by configuring the MMU to disable caching for the memory that the realtime code lives in and uses to emulate 0% hitrate. And there's usually still a fair amount of variance on top of that depending on if the memory controller has a small cache, and where the memory controller is in its refresh cycle.
For soft real time, I don't see a problem. But for hard real time, it seems a bit scary.
On some caches the line must be filled before allowing a write(ignoring any write buffer at the interface above the cache) - those basically halve the memory bandwidth when writing to a lot of cache lines. Some systems now have instructions for filling a cache line directly to avoid this. And some CPUs have bit-per-byte validity tracking to avoid this too.
Even on caches with hit-during-fill, a direct read from an address near the last-to-be-filled end of a cacheline can sometimes be a little faster than a cache miss, since the miss will fill the rest of the line first.
Intels used to boot with their caches disabled, but I haven't worked with them in forever, and never multicore.
I worked with a lot of microcontrollers, and it's not uncommon to be able to disable the instruction cache there.
There are a few things that require the data caches too, like atomic accesses on ARM. Usually we were doing something fairly short though in our realtime code, so it was easy enough to map just the memory it needed as uncacheable.