<div dir="ltr">Now I got it! Really thanks for the help.<br>I will prepare a V3.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 5, 2018 at 1:45 PM, Chris Wilson <span dir="ltr"><<a href="mailto:chris@chris-wilson.co.uk" target="_blank">chris@chris-wilson.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quoting Rodrigo Siqueira (2018-07-05 17:28:20)<br>
<span class="">> Hi and thanks for all the feedback, I will work on the suggestions you sent,<br>
> but I have some doubts:<br>
> <br>
> On 07/05, Chris Wilson wrote:<br>
> > Quoting Daniel Vetter (2018-07-05 09:20:13)<br>
> > > On Thu, Jul 05, 2018 at 12:48:43AM -0300, Rodrigo Siqueira wrote:<br>
> > > > + ktime_t current_timestamp;<br>
> > > > +<br>
> > > > + hrtimer_init(&out->vblank_<wbr>hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);<br>
> > > <br>
> > > Can't we use absolute timer mode here? That avoids all the timestampt<br>
> > > computations.<br>
> > <br>
> > Where's your absolute timestamp being computed?<br>
> <br>
> I did not understand the question. hrtimer_forward_now calculates the<br>
> absolute timestamp from the relative value provided, this is what I am<br>
> using. In any case, it would be easy to switch to absolute mode, but<br>
> the code would not be smaller (or larger).<br>
<br>
</span>It was a question to Daniel, trying to illustrate that REL is just<br>
a convenience in the htrimer api over ABS.<br>
<span class=""> <br>
> > What's being done is recomputing what hrtimer already knows given a<br>
> > relative interval. output->expires should be equivalent to<br>
> > hrtimer->expires, and a lot of this code evaporates.<br>
> <br>
> Indeed, output->expires can be removed; as for the rest of the code, that<br>
> depends on the answer to question 2 below.<br>
> <br>
> I have two questions:<br>
> <br>
> 1. The timestamp that is returned to userspace is (A) the timestamp when the<br>
> interrupt was actually handled, allowing applications to detect when there<br>
> is some irregularities in the interrupt handling timing, or (B) the timestamp<br>
> when the current interrupt was *scheduled* to happen, allowing applications<br>
> to detect overruns but not variations in the interrupt handling timing?<br>
<br>
</span>When the previous hrtimer actually occurred rolled back to the actual<br>
start of frame, i.e.<br>
<br>
hrtimer_forward_now(hrtimer, vblank_interval);<br>
output->last_vblank_timestamp =<br>
ktime_sub(hrtimer->expires, vblank_interval);<br>
<br>
userspace is mainly oblivious to the delivery latency (although it can<br>
measure it as clock_gettim() - vblank->timestamp), but is concerned<br>
about knowing what the current and next vblank HW timing will be.<br>
<span class=""><br>
> 2. If I use hrtimer with a period of 1s and return HRTIMER_RESTART, will I<br>
> be called back (A) 1s after the previous iteration was *scheduled to start*<br>
> (i.e., I will actually be called back at regular intervals, so that after<br>
> 1,000 iterations approximately 1,000s have elapsed) or (B) 1s after the<br>
> previous iteration *ended* (i.e., I will be called back at intervals of<br>
> 1s + the average processing time of the function, so that after 1,000<br>
> iterations significantly more than 1,000s have elapsed)?<br>
<br>
</span>No. When you get callback is controlled by the value you set in<br>
hrtimer->expires before you return RESTART. All RESTART does is<br>
immediately requeue the hrtimer, but more efficiently than calling<br>
hrtimer_start yourself. It is the call to hrtimer_forward that computes<br>
the next absolute hrtimer->expires based on the current time and your<br>
vblank interval.<br>
<span class=""> <br>
> The code I wrote assumes the answer to both questions is (B). If the<br>
> answer to the second question is A, the code can indeed be made much<br>
> simpler; if the answer to the first question is A, I have not been able<br>
> to keep timing within the expected strict limits of the IGT test in a VM<br>
> (maybe on physical hardware things would go better).<br>
<br>
</span>The code you wrote is actually A. hrtimer_forward() rolls the absolute<br>
timer forward such that its expiry is the next interval after now. It is<br>
while (hrtimer->expires < now)<br>
hrtimer->expires += interval;<br>
-Chris<br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><u><span style="color:rgb(255,0,0)"> </span></u><br>Rodrigo Siqueira<div>Graduate Student</div><div>Department of Computer Science</div>University of São Paulo</div></div></div></div></div></div></div></div>
</div>