aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorChris Wilson <[email protected]>2020-06-12 13:39:49 +0100
committerChris Wilson <[email protected]>2020-06-13 10:30:01 +0100
commit2267f68404d48b99ddda1728ceeedf6157b493fa (patch)
tree311cd2f1fc35e07e7b69cb1fc8d0e436794cb12d /tools/perf/scripts/python/stackcollapse.py
parentd4b02a4c613e82a4c47bf9dd228c38a2c3c1a6d2 (diff)
drm/i915/gt: Flush gen3 relocs harder, again
gen3 does not fully flush MI stores to memory on MI_FLUSH, such that a subsequent read from e.g. the sampler can bypass the store and read the stale value from memory. This is a serious issue when we are using MI stores to rewrite the batches for relocation, as it means that the batch is reading from random user/kernel memory. While it is particularly sensitive [and detectable] for relocations, reading stale data at any time is a worry. Having started with a small number of delaying stores and doubling until no more incoherency was seen over a few hours (with and without background memory pressure), 32 was the magic number. Note that it definitely doesn't fix the issue, merely adds a long delay between requests, sufficient to mostly hide the problem, enough to raise the mtbf to several hours. This is merely a stop gap. v2: Follow more closer with the gen5 w/a and include some post-invalidate flushes as well. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2018 References: a889580c087a ("drm/i915: Flush GPU relocs harder for gen3") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions