[Bug 93847] GuC is calling a sleeping function in atomic context

[bugzilla-daemon at freedesktop.org]

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

--- Comment #4 from david.s.gordon at intel.com ---
(In reply to Chris Wilson from comment #2)
> So things to note here: Using a single page for a workqueue (256 entries) is
> still more than the number of requests we can fit into a ringbuffer and so
> does not become the ratelimiting factor on submission, i.e. we can more to a
> single page and a persistent kmap and speed things up with simpler code.

'Fraid not, the workqueue size is fixed by the firmware, we don't get to choose
whether to use one page or two (or four).

Secondly, the WQ is shared between all engines. Then the GuC demultiplexes
requests into separate submissison queues internally. So one page might not be
enough if all engines were really busy.

OTOH with the scheduler we flow-control submissions at an earlier stage, so at
that point we can be sure that the GuC WQ will not be a bottleneck.

> There are quite a few ABI issues (returning incorrect timeouts to userspace
> etc) and ignored error propagation leading to silly bugs in GuC submission,
> and many dubious decisions like atomic64_cmpxchg!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20160421/f06919c1/attachment.html>