<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 16/01/2019 18:04, Lionel Landwerlin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ced9e95d-c2eb-0398-adc4-e174a35ca180@intel.com">On
16/01/2019 16:31, Chris Wilson wrote:
<br>
<blockquote type="cite">Quoting Lionel Landwerlin (2019-01-16
16:25:26)
<br>
<blockquote type="cite">On 16/01/2019 16:05, Chris Wilson wrote:
<br>
<blockquote type="cite">Quoting Lionel Landwerlin (2019-01-16
15:58:00)
<br>
<blockquote type="cite">On 16/01/2019 15:52, Chris Wilson
wrote:
<br>
<blockquote type="cite">Quoting Lionel Landwerlin
(2019-01-16 15:36:20)
<br>
<blockquote type="cite">@@ -1877,6 +1883,21 @@ struct
drm_i915_private {
<br>
wait_queue_head_t poll_wq;
<br>
bool pollin;
<br>
+ /**
<br>
+ * Atomic counter incremented
by the interrupt
<br>
+ * handling code for each OA
half full interrupt
<br>
+ * received.
<br>
+ */
<br>
+ atomic64_t half_full_count;
<br>
+
<br>
+ /**
<br>
+ * Copy of the atomic
half_full_count that was last
<br>
+ * processed in the i915-perf
driver. If both counters
<br>
+ * differ, there is data
available to read in the OA
<br>
+ * buffer.
<br>
+ */
<br>
+ u64 half_full_count_last;
<br>
</blockquote>
Eh? But why a relatively expensive atomic64. You only
need one bit, and
<br>
reading the tail pointer from WB memory should just be
cheap. You should
<br>
be able to sample the perf ringbuffer pointers very
cheaply... What am I
<br>
missing?
<br>
-Chris
<br>
<br>
</blockquote>
Fair comment.
<br>
<br>
The thing is with this series there are 2 mechanism that
notify the poll_wq.
<br>
<br>
One is the hrtimer that kicks in at regular interval and
polls the
<br>
register with the workaround.
<br>
<br>
The other is the interrupt which doesn't read the
registers and workaround.
<br>
</blockquote>
What's the complication with the workaround?
<br>
</blockquote>
<br>
It's a bit more than just looking at registers, we actually
have to look
<br>
at the content of the buffer to figure out what landed in
memory.
<br>
<br>
The register values are not synchronized with the memory
writes...
<br>
</blockquote>
I don't want to look at registers at all for polling, and you
shouldn't
<br>
need to since communication is via a ringbuf.
<br>
<blockquote type="cite">There is a comment in the code
(i915_perf_poll_locked) about not
<br>
checking the register after each wakeup because that may be a
very hot path.
<br>
<br>
The atomic64 sounded like a lesser evil.
<br>
</blockquote>
I'm clearly not understanding something here...
<br>
<br>
Does the hardware not do:
<br>
update ringbuf data;
<br>
wmb() (or post to global observation point in their
parlance)
<br>
update ringbuf tail
<br>
</blockquote>
<br>
<br>
As far as I understand, the OA unit :
<br>
<br>
sends its memory write requests to the memory controller
<br>
<br>
immediately updates the ringbuf tail, without waiting for the
previous requests to complete
<br>
<br>
</blockquote>
<br>
By experimentation, I've haven't seen a delta between what is
available in memory and what the OA tail register indicate larger
than 768 bytes, which is about 3 OA reports at the largest size.<br>
There is probably a maximum number of write requests the OA unit can
queue before blocking.<br>
<br>
So again maybe you would prefer a 2 stage mechanism :<br>
<br>
<pre>OA interrupt -----> head/tail pointer worker -----> wake up userspace</pre>
<pre> hrtimer head/tail pointer --|</pre>
<p><br>
</p>
<blockquote type="cite"
cite="mid:ced9e95d-c2eb-0398-adc4-e174a35ca180@intel.com">
<br>
<br>
<blockquote type="cite">
<br>
Then we just need to sample the ringbuf tail and compare against
how far
<br>
we read last time?
<br>
-Chris
<br>
<br>
</blockquote>
<br>
_______________________________________________
<br>
Intel-gfx mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Intel-gfx@lists.freedesktop.org">Intel-gfx@lists.freedesktop.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/intel-gfx">https://lists.freedesktop.org/mailman/listinfo/intel-gfx</a>
<br>
</blockquote>
<p><br>
</p>
</body>
</html>