[Intel-gfx] [PATCH 11/38] drm/i915: Introduce an internal allocator for disposable private objects

[Joonas Lahtinen]

On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote:
> Quite a few of our objects used for internal hardware programming do not
> benefit from being swappable or from being zero initialised. As such
> they do not benefit from using a shmemfs backing storage and since they
> are internal and never directly exposed to the user, we do not need to
> worry about providing a filp. For these we can use an
> drm_i915_gem_object wrapper around a sg_table of plain struct page. They
> are not swapped backed and not automatically pinned. If they are reaped

"swap backed"

> by the shrinker, the pages are released and the contents discarded. For
> the internal use case, this is fine as for example, ringbuffers are
> pinned from being written by a request to be read by the hardware. Once
> they are idle, they can be discarded entirely. As such they are a good
> match for execlist ringbuffers and a small varierty of other internal
> objects.
> 
> In the first iteration, this is limited to the scratch batch buffers we
> use (for command parsing and state inaitialisation).
> 
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>

> +++ b/drivers/gpu/drm/i915/i915_gem_internal.c
> @@ -0,0 +1,156 @@
> +/*
> + * Copyright © 2015 Intel Corporation

2016 already.

> +#include <drm/drmP.h>
> +#include <drm/i915_drm.h>
> +#include "i915_drv.h"
> +
> +static void __i915_gem_object_free_pages(struct sg_table *st)

Name makes me feel like this was be misplaced here. Maybe just
__object_free_pages or similar.

> +static int i915_gem_object_get_pages_internal(struct drm_i915_gem_object *obj)
> +{

Much copied from i915_gem_object_get_pages_gtt, not sure if there's
place for code reuse. Copy paste and modify not my favourite.

> +}
> +
> +static void i915_gem_object_put_pages_internal(struct drm_i915_gem_object *obj)
> +{
> +	__i915_gem_object_free_pages(obj->pages);
> +
> +	obj->dirty = 0;
> +	obj->madv = I915_MADV_WILLNEED;

This seems so backwards it might be worth a comment. It's written kind
of inverted just to dodge the usual code paths, right? I'm not sure if
it helps the code readability.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation