Re: [PATCH v2 1/3] drm/i915: Use the MRU stack search after evicting

[Joonas Lahtinen <joonas.lahtinen@linux.intel.com>]

On ke, 2017-01-11 at 11:23 +0000, Chris Wilson wrote:
> When we evict from the GTT to make room for an object, the hole we
> create is put onto the MRU stack inside the drm_mm range manager. On the
> next search pass, we can speed up a PIN_HIGH allocation by referencing
> that stack for the new hole.
> 
> v2: Pull together the 3 identical implements (ahem, a couple were
> outdated) into a common routine for allocating a node and evicting as
> necessary.
> v3: Detect invalid calls to i915_gem_gtt_insert()
> v4: kerneldoc
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

<SNIP>

> +/**
> + * i915_gem_gtt_insert - insert a node into an address_space (GTT)
> + * @vm - the &struct i915_address_space

mixing &struct and @struct, I guess you meant &struct in later line
too.

> + * @node - the @struct drm_mm_node (typicallay i915_vma.mode)

"typicallly" and "i915_vma.node"

> + * @size - how much space to allocate inside the GTT,
> + *         must be #I915_GTT_PAGE_SIZE aligned
> + * @alignment - required alignment of starting offset, may be 0 but
> + *              if specified, this must be a power-of-two and at least
> + *              #I915_GTT_MIN_ALIGNMENT
> + * @color - color to apply to node
> + * @start - start of any range restriction inside GTT (0 for all),
> + *          must be #I915_GTT_PAGE_SIZE aligned
> + * @end - end of any range restriction inside GTT (U64_MAX for all),
> + *        must be #I915_GTT_PAGE_SIZE aligned
> + * @flags - control search and eviction behaviour
> + *
> + * i915_gem_gtt_insert() first searches for an available hole into which
> + * is can insert the node. The hole address is aligned to @alignment and
> + * its @size must then fit entirely within the [@start, @end] bounds. The
> + * nodes on either side of the hole must match @color, or else a guard page
> + * will be inserted between the two nodes (or the node evicted). If no
> + * suitable hole is found, then the LRU list of objects within the GTT
> + * is scanned to find the first set of replacement nodes to create the hole.
> + * Those old overlapping nodes are evicted from the GTT (and so must be
> + * rebound before any future use). Any node that is current pinned cannot

"currently"

> + * be evicted (see i915_vma_pin()). Similar if the node's VMA is currently
> + * active and #PIN_NONBLOCK is specified, that node is also skipped when
> + * searching for an eviction candidate. See i915_gem_evict_something() for
> + * the gory details on the eviction algorithm.
> + *
> + * Returns: 0 on success, -ENOSPC if no suitable hole is found, -EINTR if
> + * asked to wait for eviction and interrupted.
> + */

Fit those fixed, good to merge.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx