diff options
Diffstat (limited to 'en/devices/tech/debug/systrace.html')
| -rw-r--r-- | en/devices/tech/debug/systrace.html | 38 |
1 files changed, 20 insertions, 18 deletions
diff --git a/en/devices/tech/debug/systrace.html b/en/devices/tech/debug/systrace.html index 4334f9d9..036bd6da 100644 --- a/en/devices/tech/debug/systrace.html +++ b/en/devices/tech/debug/systrace.html @@ -49,7 +49,9 @@ problems. (These features require root access and often a new kernel.)</p> <p>When debugging jitter on Pixel/Pixel XL, start with the following command:</p> -<pre>$ ./systrace.py sched freq idle am wm gfx view sync binder_driver irq workq input -b 96000</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +./systrace.py sched freq idle am wm gfx view sync binder_driver irq workq input -b 96000 +</pre> <p>When combined with the additional tracepoints required for GPU and display pipeline activity, this gives you the ability to trace from user input to frame @@ -106,7 +108,7 @@ back to sleep, waiting for EventThread wakeup.</li> <p>Let's walk through the frame beginning at 15409ms:</p> -<p><img src="images/perf_trace_normal_pipeline.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_normal_pipeline.png"></p> <p class="img-caption"><strong>Figure 1.</strong> Normal UI pipeline, EventThread running.</p> @@ -139,14 +141,14 @@ sleep slice.</p> <p>While EventThread is running, the UI thread for TouchLatency becomes runnable. To see what woke it, click the blue section:</p> -<p><img src="images/perf_trace_tl.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_tl.png"></p> <p class="img-caption"><strong>Figure 2.</strong> UI thread for TouchLatency.</p> <p>Figure 2 shows the TouchLatency UI thread was woken by tid 6843, which corresponds to EventThread. The UI thread wakes:</p> -<p><img src="images/perf_trace_wake_render_enqueue.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_wake_render_enqueue.png"></p> <p class="img-caption"><strong>Figure 3.</strong> UI thread wakes, renders a frame, and enqueues it for SurfaceFlinger to consume.</p> @@ -154,7 +156,7 @@ frame, and enqueues it for SurfaceFlinger to consume.</p> binder transaction to view information on all of the processes involved in that transaction:</p> -<p><img src="images/perf_trace_binder_trans.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_binder_trans.png"></p> <p class="img-caption"><strong>Figure 4.</strong> Binder transaction.</p> <p>Figure 4 shows that, at 15,423.65ms, Binder:6832_1 in SurfaceFlinger becomes @@ -164,7 +166,7 @@ see queueBuffer on both sides of the binder transaction.</p> <p>During the queueBuffer on the SurfaceFlinger side, the number of pending frames from TouchLatency goes from 1 to 2:</p> -<p><img src="images/perf_trace_pending_frames.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_pending_frames.png"></p> <p class="img-caption"><strong>Figure 5.</strong> Pending frames goes from 1 to 2.</p> @@ -176,14 +178,14 @@ further dropped frames.</p> <p>Soon after, SurfaceFlinger's main thread is woken by a second EventThread so it can output the older pending frame to the display:</p> -<p><img src="images/perf_trace_sf_woken_et.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_sf_woken_et.png"></p> <p class="img-caption"><strong>Figure 6.</strong> SurfaceFlinger's main thread is woken by a second EventThread.</p> <p>SurfaceFlinger first latches the older pending buffer, which causes the pending buffer count to decrease from 2 to 1:</p> -<p><img src="images/perf_trace_sf_latches_pend.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_sf_latches_pend.png"></p> <p class="img-caption"><strong>Figure 7.</strong> SurfaceFlinger first latches the older pending buffer.</p> @@ -191,7 +193,7 @@ the older pending buffer.</p> final frame to the display. (Some of these sections are enabled as part of the <code>mdss</code> tracepoint, so they may not be there on your SOC.)</p> -<p><img src="images/perf_trace_sf_comp_submit.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_sf_comp_submit.png"></p> <p class="img-caption"><strong>Figure 8.</strong> SurfaceFlinger sets up composition and submits the final frame.</p> @@ -200,7 +202,7 @@ display pipeline's kernel thread for outputting a rendered frame to the display. We can see <code>mdss_fb0</code> as its own row in the trace (scroll down to view).</p> -<p><img src="images/perf_trace_wake_cpu0.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_wake_cpu0.png"></p> <p class="img-caption"><strong>Figure 9.</strong> <code>mdss_fb0</code> wakes on CPU 0.</p> @@ -215,14 +217,14 @@ the Pixel XL might not be useful to you).</p> <h2 id="example_2">Example: Non-working frame</h2> <p>This example describes a systrace used to debug Pixel/Pixel XL jitter. To -follow along with the example, <a href="perf_traces.zip">download the zip +follow along with the example, <a href="/devices/tech/debug/perf_traces.zip">download the zip file</a> of traces (which also includes other traces referred to in this section), upzip the file, and open the systrace_tutorial.html file in your browser.</p> <p>When you first open the systrace, you'll see something like this:</p> -<p><img src="images/perf_trace_tl_pxl.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_tl_pxl.png"></p> <p class="img-caption"><strong>Figure 10</strong>. TouchLatency running on Pixel XL (most options enabled, including mdss and kgsl tracepoints).</p> @@ -234,7 +236,7 @@ case, FrameMissed is correlated with SurfaceFlinger missing one of its extremely-regular runtimes and an unchanged pending-buffer count for the app (<code>com.prefabulated.touchlatency</code>) at a vsync:</p> -<p><img src="images/perf_trace_fm_sf.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_fm_sf.png"></p> <p class="img-caption"><strong>Figure 11</strong>. FrameMissed correlation with SurfaceFlinger.</p> @@ -250,7 +252,7 @@ SurfaceFlinger wakes and immediately goes to sleep. When viewing the number of pending frames from TouchLatency, there are two frames (a good clue to help figure out what's going on).</p> -<p><img src="images/perf_trace_sf_wake_sleep.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_sf_wake_sleep.png"></p> <p class="img-caption"><strong>Figure 12.</strong> SurfaceFlinger wakes and immediately goes to sleep.</p> @@ -269,7 +271,7 @@ particular events in SurfaceFlinger depends on your SOC and driver stack, so work with your SOC vendor to understand the meaning of fence categories in your traces.</p> -<p><img src="images/perf_traces_fences.png"></p> +<p><img src="/devices/tech/debug/images/perf_traces_fences.png"></p> <p class="img-caption"><strong>Figure 13.</strong> <code>mdss_fb0_retire</code> fences.</p> @@ -277,7 +279,7 @@ fences.</p> Halfway through that slice, that frame should have been replaced by a new one but wasn't. View the previous frame and look for anything interesting:</p> -<p><img src="images/perf_trace_frame_previous.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_frame_previous.png"></p> <p class="img-caption"><strong>Figure 14.</strong> Frame previous to busted frame.</p> @@ -288,7 +290,7 @@ suggests that something is very wrong with the display pipe.</p> <p>Investigate exactly where that fence ends to determine what controls it:</p> -<p><img src="images/perf_trace_fence_end.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_fence_end.png"></p> <p class="img-caption"><strong>Figure 15.</strong> Investigate fence end.</p> <p>A workqueue contains a <code>__vsync_retire_work_handler</code> that is @@ -301,7 +303,7 @@ might not get scheduled accurately.</p> <p>Check the previous frame to determine if that contributed; sometimes jitter can add up over time and eventually cause us to miss a deadline.</p> -<p><img src="images/perf_trace_previous_frame.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_previous_frame.png"></p> <p class="img-caption"><strong>Figure 16.</strong> Previous frame.</p> <p>The runnable line on the kworker isn't visible because the viewer turns it |