| Summary: | [IVB/HSW ULT Bisected]igt/gem_cs_prefetch costs long time to execute | ||||||
|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Guo Jinxian <jinxianx.guo> | ||||
| Component: | DRM/Intel | Assignee: | Chris Wilson <chris> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
| Severity: | normal | ||||||
| Priority: | high | CC: | intel-gfx-bugs | ||||
| Version: | unspecified | ||||||
| Hardware: | Other | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
Yeah, bisect should be interesting. 9403eb1064168ea7b47c5ccd04ec17b98ca9a0de is the first bad commit commit 9403eb1064168ea7b47c5ccd04ec17b98ca9a0de Author: Chris Wilson <chris@chris-wilson.co.uk> AuthorDate: Mon Mar 17 12:21:55 2014 +0000 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Fri Apr 25 16:18:01 2014 +0200 drm/i915: Do not call retire_requests from wait_for_rendering A common issue we have is that retiring requests causes recursion through GTT manipulation or page table manipulation which we can only handle at very specific points. However, to maintain internal consistency (enforced through our sanity checks on write_domain at various points in the GEM object lifecycle) we do need to retire the object prior to marking it with a new write_domain, and also clear the write_domain for the implicit flush following a batch. Note that this then allows the unbound objects to still be on the active lists, and so care must be taken when removing objects from unbound lists (similar to the caveats we face processing the bound lists). v2: Fix i915_gem_shrink_all() to handle updated object lifetime rules, by refactoring it to call into __i915_gem_shrink(). v3: Missed an object-retire prior to changing cache domains in i915_gem_object_set_cache_leve() v4: Rebase Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> :040000 040000 469c92ff9c22309ca81fa43a75c249c1112b69da a036ee8486228ba2ddc646c607595011a31cdde7 M drivers Revert the commit, the case works well *** This bug has been marked as a duplicate of bug 78023 *** Jinxian, please verify. Verified on latest -nightly(77820625217fa547586f00be7cae56e5c5e255bf) [root@x-ivb9 tests]# time ./gem_cs_prefetch IGT-Version: 1.7-g3f50598 (x86_64) (Linux: 3.16.0-rc5_drm-intel-nightly_778206_20140716+ x86_64) gem_cs_prefetch: 100% Test suceeded, cleanup up - this might take a while. real 0m21.041s user 0m1.086s sys 0m15.625s Closing verified+duplicate as duplicate of closed+fixed. |
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.
Created attachment 98404 [details] dmesg *System Environment: -------------------------- Platform: IVB HSW ULT kernel: -nightly: 08ce6614d07dd1e426109672a5e323317c8d6ec7(fails) -queued: e5c03ca362819ba8ffbe5674340b61b9cd75de8f (fails) -fixes: 9bbfd20abe5025adbb0ac75160bd2e41158a9e83 (works) *Bug detailed description: ----------------------------- igt/gem_cs_prefetch costs long time to execute, it costs about 11 minutes to finish. It's a regression bug Good commit: bb8786a44c6042ec8a85370466a8bd400a079bdc Bad commit: e5c03ca362819ba8ffbe5674340b61b9cd75de8f We will bisect is later Output: date;./gem_cs_prefetch;date Sun May 4 16:17:43 EDT 2014 IGT-Version: 1.6-gc864279 (x86_64) (Linux: 3.14.0_drm-intel-next-queued_e5c03c_20140504+ x86_64) gem_cs_prefetch: 100% Test suceeded, cleanup up - this might take a while. Sun May 4 16:27:58 EDT 2014 *Reproduce steps: ---------------------------- 1. ./gem_cs_prefetch