On 2026-10-05 17:05:14+01:00, Steven Price wrote: > On 05/10/2026 16:37, Boris Brezillon wrote: > > > On Mon, 5 Oct 2026 16:06:02 +0100 > > Steven Price <[email protected]> wrote: > > > > > > Hm, I'd say it's actually impossible because every unmap operation is > > followed by a flush+inval of the GPU L2 and LSC, so for this stale > > clean line to exist on the GPU side when a physical page is GPU-mapped > > again, it would take a bug in the unmap logic or in the MMU HW, I > > think. Am I missing something? > > Ah, yes that's true :) Although there's no need for us to do an > invalidate on the unmap path...
Does that mean the panfrost_mmu_flush_range() we do at the end of panfrost_mmu_unmap() is unnecessary? Is it because, as you said in a previous message, cache lines for BOs referenced in a CS are always invalidates before anything else is executed? If we keep the invalidate at the end of the mmu path, then there would be no need to mention that all counters being enabled is the ultimate reason why no initial flush/invalidate is needed in the perfcnt enable path. > >> > > > > I suppose speculation pre-populating the caches with stale data would be > > covered by the flush+inval we do after a map operation (this is > > currently done in the unlock path regardless of the VM op, so both map > > and unmap get it). I don't know, maybe the goal is to relax the flushing > > policy around VM modifications in the future, but if things stay as > > they are now, we can assume that a fresh BO being GPU-mapped guarantees > > that no cacheline points to it until the first GPU access. But maybe > > I'm missing something else... > > I have to admit I'm coming from experience on CPUs - there speculation > means a CPU can load a cache line at basically any point. So the > argument that a line cannot be in a cache almost never holds. GPUs (at > least Mali GPUs) haven't quite got to the stage of CPUs. > > Thanks, > Steve
