From: Daniel Vetter <daniel@ffwll.ch>
To: Damien Lespiau <damien.lespiau@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 8/9] drm/i915: Flush GPU rendering with a lockless wait during a pagefault
Date: Mon, 10 Feb 2014 18:32:29 +0100 [thread overview]
Message-ID: <20140210173228.GC17001@phenom.ffwll.local> (raw)
In-Reply-To: <20140210155200.GJ9282@strange.amr.corp.intel.com>
On Mon, Feb 10, 2014 at 03:52:00PM +0000, Damien Lespiau wrote:
> On Fri, Feb 07, 2014 at 06:37:06PM -0200, Rodrigo Vivi wrote:
> > From: Chris Wilson <chris@chris-wilson.co.uk>
> >
> > Arjan van de Ven reported that on his test machine that he was seeing
> > stalls of greater than 1 frame greatly impacting the user experience. He
> > tracked this down to being the locked flush during a pagefault as being
> > the culprit hogging the struct_mutex and so blocking any other user from
> > proceeding. Stalling on a pagefault is bad behaviour on userspace's
> > part, for one it means that they are ignoring the coherency rules on
> > pointer access through the GTT, but fortunately we can apply the same
> > trick as the set-to-domain ioctl to do a lightweight, nonblocking flush
> > of outstanding rendering first.
> >
> > "Prior to the patch it looks like this
> > (this one testrun does not show the 20ms+ I've seen occasionally)
> >
> > 4.99 ms 2.36 ms 31360 __wait_seqno i915_wait_seqno i915_gem_object_wait_rendering i915_gem_object_set_to_gtt_domain i915_gem_fault __do_fault handle_
> > +pte_fault handle_mm_fault __do_page_fault do_page_fault page_fault
> > 4.99 ms 2.75 ms 107751 __wait_seqno i915_gem_wait_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
> > 4.99 ms 1.63 ms 1666 i915_mutex_lock_interruptible i915_gem_fault __do_fault handle_pte_fault handle_mm_fault __do_page_fault do_page_fault page_fa
> > +ult
> > 4.93 ms 2.45 ms 980 i915_mutex_lock_interruptible intel_crtc_page_flip drm_mode_page_flip_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_
> > +sysret
> > 4.89 ms 2.20 ms 3283 i915_mutex_lock_interruptible i915_gem_wait_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
> > 4.34 ms 1.66 ms 1715 i915_mutex_lock_interruptible i915_gem_pwrite_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
> > 3.73 ms 3.73 ms 49 i915_mutex_lock_interruptible i915_gem_set_domain_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
> > 3.17 ms 0.33 ms 931 i915_mutex_lock_interruptible i915_gem_madvise_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
> > 2.97 ms 0.43 ms 1029 i915_mutex_lock_interruptible i915_gem_busy_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
> > 2.55 ms 0.51 ms 735 i915_gem_get_tiling drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
> >
> > After the patch it looks like this:
> >
> > 4.99 ms 2.14 ms 22212 __wait_seqno i915_gem_wait_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
> > 4.86 ms 0.99 ms 14170 __wait_seqno i915_gem_object_wait_rendering__nonblocking i915_gem_fault __do_fault handle_pte_fault handle_mm_fault __do_page_
> > +fault do_page_fault page_fault
> > 3.59 ms 1.31 ms 325 i915_gem_get_tiling drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
> > 3.37 ms 3.37 ms 65 i915_mutex_lock_interruptible i915_gem_wait_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
> > 2.58 ms 2.58 ms 65 i915_mutex_lock_interruptible i915_gem_do_execbuffer.isra.23 i915_gem_execbuffer2 drm_ioctl i915_compat_ioctl compat_sys_ioctl
> > +ia32_sysret
> > 2.19 ms 2.19 ms 65 i915_mutex_lock_interruptible intel_crtc_page_flip drm_mode_page_flip_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_
> > +sysret
> > 2.18 ms 2.18 ms 65 i915_mutex_lock_interruptible i915_gem_busy_ioctl drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
> > 1.66 ms 1.66 ms 65 i915_gem_set_tiling drm_ioctl i915_compat_ioctl compat_sys_ioctl ia32_sysret
> >
> > It may not look like it, but this is quite a large difference, and I've
> > been unable to reproduce > 5 msec delays at all, while before they do
> > happen (just not in the trace above)."
> >
> > gem_gtt_hog on an old Pineview (GMA3150),
> > before: 4969.119ms
> > after: 4122.749ms
> >
> > Reported-by: Arjan van de Ven <arjan.van.de.ven@intel.com>
> > Testcase: igt/gem_gtt_hog
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
>
> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-02-10 17:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-07 20:36 [PATCH 0/9] drm-intel-collector - update Rodrigo Vivi
2014-02-07 20:36 ` [PATCH 1/9] drm/i915: Propagate errors on failed PPGTT Rodrigo Vivi
2014-02-07 20:37 ` [PATCH 2/9] drm/i915: wrap crtc enable/disable Rodrigo Vivi
2014-02-07 20:37 ` [PATCH 3/9] drm/i915: make crtc enable/disable asynchronous Rodrigo Vivi
2014-03-03 23:18 ` Jesse Barnes
2014-02-07 20:37 ` [PATCH 4/9] drm/i915: Propagate PCI read/write errors during vga_set_state() Rodrigo Vivi
2014-02-10 10:35 ` Daniel Vetter
2014-02-07 20:37 ` [PATCH 5/9] drm/i915: Short-circuit no-op vga_set_state() Rodrigo Vivi
2014-02-10 10:36 ` Daniel Vetter
2014-02-07 20:37 ` [PATCH 6/9] drm/i915: Verify address field of PCBR register Rodrigo Vivi
2014-02-07 20:37 ` [PATCH 7/9] drm/i915: Bring UP Power Wells before disabling RC6 Rodrigo Vivi
2014-02-07 20:37 ` [PATCH 8/9] drm/i915: Flush GPU rendering with a lockless wait during a pagefault Rodrigo Vivi
2014-02-10 15:52 ` Damien Lespiau
2014-02-10 17:32 ` Daniel Vetter [this message]
2014-02-07 20:37 ` [PATCH 9/9] drm/i915: PF CRC may not work on HSW Rodrigo Vivi
2014-02-10 10:43 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140210173228.GC17001@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=damien.lespiau@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox