[Mesa-dev] [Bug 86690] glmark2-es2-wayland shortly freezes on some frames with egl_dri2 backend (Nouveau/GK20A)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=86690

--- Comment #4 from Alexandre Courbot <gnurou at gmail.com> ---
As discussed on IRC, it appears that running "perf top" at the same time as any
Weston EGL client delivers the same behavior of frozen frames in said client,
without affecting Weston itself or other non-EGL clients. "perf top" reports a
high usage (~30% CPU time) of _raw_spin_unlock_irq() *only* when the condition
occurs.

Very strange. I have run strace on the EGL client for both conditions
(non-bound EGL program, and EGL program while "perf top" is running), and
noticed that these freezes correspond to long consecutive series of calls to
sched_yield(), e.g:

17:42:56.337425 sched_yield()           = 0
17:42:56.337830 sched_yield()           = 0
...
17:42:57.713679 sched_yield()           = 0
17:42:57.714122 sched_yield()           = 0

sched_yield() is never called in the case of a well-behaving client.

Grepping into Mesa, I found one loop in nouveau_fence_wait() where
sched_yield() is called. Removing this call does not fix the issue, but the
calls the sched_yield() are not visible in the trace anymore, which tends to
confirm this is where the misbehavior is happening.

The series of sched_yield() calls are always between the two following ioctls:

17:42:56.266742 ioctl(6, 0xc0406481, 0xbeeec788) = 0
17:42:56.268952 sched_yield()           = 0
17:42:56.269466 sched_yield()           = 0
...
17:42:56.281481 sched_yield()           = 0
17:42:56.281848 sched_yield()           = 0
17:42:56.282210 ioctl(6, 0xc0406481, 0xbeeec750) = 0

with the calls to sched_yield() removed, the strace log shows large delays
between these ioctls, hinting again that nouveau_fence_wait() is busy-waiting
in that loop:

17:56:00.248145 ioctl(6, 0xc0406481, 0xbecf2768) = 0
17:56:01.155312 ioctl(6, 0xc0406481, 0xbecf2730) = 0

What is really remarkable is that this is true for both cases: a non-capped EGL
client, or a (capped or non-capped) EGL client while "perf top" is running. The
same ioctls are involved, in the same pattern.

While this seems to make it clear that we are waiting for fences, I still
cannot imagine how "perf top" can have such a strong influence on this.

So it seems that in both cases we are waiting for fences. I have attached a
full strace of weston-simple-egl in case this could be helpful.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141128/722452f7/attachment.html>