On 16/02/2018 10:13, Chris Wilson wrote:
Quoting Patchwork (2018-02-15 23:50:52)
== Series Details ==
Series: drm/i915: Use seqlock in engine stats (rev2)
URL : https://patchwork.freedesktop.org/series/38347/
State : failure
== Summary ==
Test perf_pmu:
Subgroup busy-start-vcs0:
pass -> DMESG-WARN (shard-apl)
Subgroup busy-idle-check-all-vecs0:
pass -> DMESG-WARN (shard-apl)
Subgroup render-node-busy-idle-vcs0:
pass -> DMESG-WARN (shard-apl)
Subgroup most-busy-idle-check-all-bcs0:
pass -> DMESG-WARN (shard-apl)
Subgroup busy-idle-check-all-bcs0:
pass -> DMESG-WARN (shard-apl)
Subgroup most-busy-check-all-bcs0:
pass -> DMESG-WARN (shard-apl)
Subgroup render-node-busy-bcs0:
pass -> DMESG-WARN (shard-apl)
Subgroup busy-idle-vecs0:
pass -> DMESG-WARN (shard-apl)
Afaict, it's complaining that because the writer is special the reader
needs irq protection. Which I don't understand, as the point is that the
writer can run concurrently to the readers (the readers have to
restart). What am I missing?
As discussed on IRC, issue is courtesy of perf read callback running in
hardirq context, that the reader can interrupt the writer and so
incorrectly declare a stable sequence number while reading the mixed up
version of the underlying data.
Writer:
seqno++
modify some fields
<Reader IRQ...
read seqno
read fields
re-read seqno -> OK
>..Reader IRQ
modify other fields
seqno++
So we need to go back to the first, irqsave version. Do you want to
pursue this change right now or leave it for some future work?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
