| Summary: | GuC is calling a sleeping function in atomic context | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Tvrtko Ursulin <tvrtko.ursulin> |
| Component: | DRM/Intel | Assignee: | Dave Gordon <dg11491352> |
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | intel-gfx-bugs |
| Version: | DRI git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | BXT, SKL | i915 features: | power/Other |
|
Description
Tvrtko Ursulin
2016-01-25 11:37:10 UTC
Sleeping whilst atomic is just the tip of the iceberg. That's a 20 millisecond uninterruptible wait! 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. 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! Fixed by: 0d92a6a drm/i915/guc: keep GuC doorbell & process descriptor mapped in kernel (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! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.