<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - GuC is calling a sleeping function in atomic context" href="https://bugs.freedesktop.org/show_bug.cgi?id=93847#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - GuC is calling a sleeping function in atomic context" href="https://bugs.freedesktop.org/show_bug.cgi?id=93847">bug 93847</a> from <a class="email" href="mailto:david.s.gordon@intel.com" title="david.s.gordon@intel.com">david.s.gordon@intel.com</a> <pre>(In reply to Chris Wilson from <a href="show_bug.cgi?id=93847#c2">comment #2</a>) > 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!</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>