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.

  modify some fields
  <Reader IRQ...
    read seqno
    read fields
    re-read seqno -> OK
  >..Reader IRQ
  modify other fields

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?


Intel-gfx mailing list

Reply via email to