From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 15/15] drm/i915: no more agp for gem
Date: Sun, 07 Nov 2010 10:55:07 +0000 [thread overview]
Message-ID: <5b55a1$ijc8ht@fmsmga002.fm.intel.com> (raw)
In-Reply-To: <20101107102025.GA3474@viiv.ffwll.ch>
On Sun, 7 Nov 2010 11:20:26 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
> Wrt future plans: My idea behind separating the dmar mapping and the gtt
> pte writing was to be able to keep around the dmar mapping even when the
> bo is not bound to the gtt. Together with a phys_memory domain to avoid
> cflush on rebind, that should pretty much kill aperture trashing.
Lots of overlap with what I am attempting right now. I've just
approached the problem from top-down and looked at reusing dead-bo as
handles into GTT space. Keeping a page cache is essential to minimise
clflush on aperture thrashing, after that the rebind penalty is next on
the CPU profiles. The observation is that workloads tend to keep reusing
the same buffer sizes, and so we can get a very good hit rate from
keeping a deferred-free list and stealing the GTT space from those dead
bo. (Now the worst offender is scanning the deferred-free list for
victims, but a win overall.)
Approaching this from the bottom up, we can start tracking inactive bound
pages in the GTT manager, such that the rebind penalty can be avoided in
far more cases. Interesting...
For the time being, I'll keep on improving my understanding of the VM by
bugfixing my current page-stealer which (I believe) is fundamental to
transferring pages between the GTT and system/swap cheaply.
[And I may look at one or two bugs. ;-]
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
prev parent reply other threads:[~2010-11-07 10:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-06 14:21 [PATCH 00/15] The "no more agp" series Daniel Vetter
2010-11-06 14:21 ` [PATCH 01/15] intel-gtt: drop dcache support for i830 and later Daniel Vetter
2010-11-06 14:21 ` [PATCH 02/15] intel-gtt: kill unneeded sandybridge memory types Daniel Vetter
2010-11-06 14:21 ` [PATCH 03/15] intel-gtt: switch i81x to the write_entry helpers Daniel Vetter
2010-11-06 14:21 ` [PATCH 04/15] intel-gtt: switch i81x to the common initialization helpers Daniel Vetter
2010-11-06 14:21 ` [PATCH 05/15] intel-gtt: fold i81x-only dcache support into the generic driver Daniel Vetter
2010-11-06 14:21 ` [PATCH 06/15] drm/i915|intel-gtt: consolidate intel-gtt.h headers Daniel Vetter
2010-11-06 14:22 ` [PATCH 07/15] drm/i915/gtt: call chipset flush directly Daniel Vetter
2010-11-06 14:22 ` [PATCH 08/15] drm: kill drm_agp_chipset_flush Daniel Vetter
2010-11-06 14:22 ` [PATCH 09/15] agp: kill agp_flush_chipset and corresponding ioctl Daniel Vetter
2010-11-06 14:22 ` [PATCH 10/15] drm/i915: track objects in the gtt Daniel Vetter
2010-11-06 14:22 ` [PATCH 11/15] drm/i915: restore gtt on resume in the drm instead of in intel-gtt.ko Daniel Vetter
2010-11-06 14:22 ` [PATCH 12/15] agp: kill agp_rebind_memory Daniel Vetter
2010-11-06 14:22 ` [PATCH 13/15] drm/i915: move gtt handling to i915_gem_gtt.c Daniel Vetter
2010-11-06 14:22 ` [PATCH 14/15] intel-gtt: export api for drm/i915 Daniel Vetter
2010-11-06 14:22 ` [PATCH 15/15] drm/i915: no more agp for gem Daniel Vetter
2010-11-06 22:20 ` Chris Wilson
2010-11-07 10:20 ` Daniel Vetter
2010-11-07 10:55 ` Chris Wilson [this message]
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='5b55a1$ijc8ht@fmsmga002.fm.intel.com' \
--to=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--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