diff mbox

[v2,1/5] drm/i915: Implement a framework for batch buffer pools

Message ID 1404858400-18879-2-git-send-email-bradley.d.volkin@intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

bradley.d.volkin@intel.com July 8, 2014, 10:26 p.m. UTC
From: Brad Volkin <bradley.d.volkin@intel.com>

This adds a small module for managing a pool of batch buffers.
The only current use case is for the command parser, as described
in the kerneldoc in the patch. The code is simple, but separating
it out makes it easier to change the underlying algorithms and to
extend to future use cases should they arise.

The interface is simple: init to create an empty pool, fini to
clean it up; get to obtain a new buffer, put to return it to the
pool. Note that all buffers must be returned to the pool before
freeing it.

Buffers are purgeable while in the pool, but not explicitly
truncated in order to avoid overhead during execbuf.

Locking is currently based on the caller holding the struct_mutex.
We already do that in the places where we will use the batch pool
for the command parser.

v2:
- s/BUG_ON/WARN_ON/ for locking assertions
- Remove the cap on pool size
- Switch from alloc/free to init/fini

Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
---
 Documentation/DocBook/drm.tmpl             |   5 ++
 drivers/gpu/drm/i915/Makefile              |   1 +
 drivers/gpu/drm/i915/i915_drv.h            |  17 ++++
 drivers/gpu/drm/i915/i915_gem.c            |   1 +
 drivers/gpu/drm/i915/i915_gem_batch_pool.c | 133 +++++++++++++++++++++++++++++
 5 files changed, 157 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_gem_batch_pool.c

Comments

Chris Wilson July 9, 2014, 7:32 a.m. UTC | #1
On Tue, Jul 08, 2014 at 03:26:36PM -0700, bradley.d.volkin@intel.com wrote:
> +void i915_gem_batch_pool_fini(struct i915_gem_batch_pool *pool)
> +{
> +	struct drm_i915_gem_object *obj, *next;
> +
> +	WARN_ON(!mutex_is_locked(&pool->dev->struct_mutex));
> +	WARN_ON(!list_empty(&pool->active_list));
> +
> +	list_for_each_entry_safe(obj, next,
> +				 &pool->inactive_list, batch_pool_list) {
> +		list_del(&obj->batch_pool_list);
> +		drm_gem_object_unreference(&obj->base);
> +	}

Cleanup loops are idiomatically: while (!list_empty()) { }

> +struct drm_i915_gem_object *
> +i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
> +			size_t size)
> +{
> +	struct drm_i915_gem_object *obj = NULL;
> +	struct drm_i915_gem_object *tmp;
> +
> +	WARN_ON(!mutex_is_locked(&pool->dev->struct_mutex));
> +
> +	list_for_each_entry(tmp, &pool->inactive_list, batch_pool_list) {
> +		if (tmp->base.size >= size) {

A general rule-of-thumb we use elsewhere is not to hand back an object
that is greater than 2x the request. If you want to be generic, you
could change size to min_size, max_size.
-Chris
Chris Wilson July 9, 2014, 7:37 a.m. UTC | #2
On Tue, Jul 08, 2014 at 03:26:36PM -0700, bradley.d.volkin@intel.com wrote:
> From: Brad Volkin <bradley.d.volkin@intel.com>
> 
> This adds a small module for managing a pool of batch buffers.
> The only current use case is for the command parser, as described
> in the kerneldoc in the patch. The code is simple, but separating
> it out makes it easier to change the underlying algorithms and to
> extend to future use cases should they arise.
> 
> The interface is simple: init to create an empty pool, fini to
> clean it up; get to obtain a new buffer, put to return it to the
> pool. Note that all buffers must be returned to the pool before
> freeing it.
> 
> Buffers are purgeable while in the pool, but not explicitly
> truncated in order to avoid overhead during execbuf.
> 
> Locking is currently based on the caller holding the struct_mutex.
> We already do that in the places where we will use the batch pool
> for the command parser.
> 
> v2:
> - s/BUG_ON/WARN_ON/ for locking assertions
> - Remove the cap on pool size
> - Switch from alloc/free to init/fini

You are missing the madvise mechanics.
-Chris
bradley.d.volkin@intel.com July 9, 2014, 3:10 p.m. UTC | #3
On Wed, Jul 09, 2014 at 12:37:08AM -0700, Chris Wilson wrote:
> On Tue, Jul 08, 2014 at 03:26:36PM -0700, bradley.d.volkin@intel.com wrote:
> > From: Brad Volkin <bradley.d.volkin@intel.com>
> > 
> > This adds a small module for managing a pool of batch buffers.
> > The only current use case is for the command parser, as described
> > in the kerneldoc in the patch. The code is simple, but separating
> > it out makes it easier to change the underlying algorithms and to
> > extend to future use cases should they arise.
> > 
> > The interface is simple: init to create an empty pool, fini to
> > clean it up; get to obtain a new buffer, put to return it to the
> > pool. Note that all buffers must be returned to the pool before
> > freeing it.
> > 
> > Buffers are purgeable while in the pool, but not explicitly
> > truncated in order to avoid overhead during execbuf.
> > 
> > Locking is currently based on the caller holding the struct_mutex.
> > We already do that in the places where we will use the batch pool
> > for the command parser.
> > 
> > v2:
> > - s/BUG_ON/WARN_ON/ for locking assertions
> > - Remove the cap on pool size
> > - Switch from alloc/free to init/fini
> 
> You are missing the madvise mechanics.

_get() and _put() set obj->madv, which I thought was enough for what I've
described (i.e. purgeable while in the pool but not explicitly truncated).
Is that not enough for the shrinker to truncate as needed? Or do you want
them explicitly truncated while in the pool? I was worried about the extra
cost of getting the backing storage back during execbuf.

Brad

> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre
Chris Wilson July 9, 2014, 3:30 p.m. UTC | #4
On Wed, Jul 09, 2014 at 08:10:47AM -0700, Volkin, Bradley D wrote:
> On Wed, Jul 09, 2014 at 12:37:08AM -0700, Chris Wilson wrote:
> > On Tue, Jul 08, 2014 at 03:26:36PM -0700, bradley.d.volkin@intel.com wrote:
> > > From: Brad Volkin <bradley.d.volkin@intel.com>
> > > 
> > > This adds a small module for managing a pool of batch buffers.
> > > The only current use case is for the command parser, as described
> > > in the kerneldoc in the patch. The code is simple, but separating
> > > it out makes it easier to change the underlying algorithms and to
> > > extend to future use cases should they arise.
> > > 
> > > The interface is simple: init to create an empty pool, fini to
> > > clean it up; get to obtain a new buffer, put to return it to the
> > > pool. Note that all buffers must be returned to the pool before
> > > freeing it.
> > > 
> > > Buffers are purgeable while in the pool, but not explicitly
> > > truncated in order to avoid overhead during execbuf.
> > > 
> > > Locking is currently based on the caller holding the struct_mutex.
> > > We already do that in the places where we will use the batch pool
> > > for the command parser.
> > > 
> > > v2:
> > > - s/BUG_ON/WARN_ON/ for locking assertions
> > > - Remove the cap on pool size
> > > - Switch from alloc/free to init/fini
> > 
> > You are missing the madvise mechanics.
> 
> _get() and _put() set obj->madv, which I thought was enough for what I've
> described (i.e. purgeable while in the pool but not explicitly truncated).
> Is that not enough for the shrinker to truncate as needed? Or do you want
> them explicitly truncated while in the pool? I was worried about the extra
> cost of getting the backing storage back during execbuf.

You need to check that the shrinker hasn't truncated your backing
storage whilst it was marked DONTNEED. It just amounts to checking for
obj->madv == __I915_MADV_PURGED in pool_get() and discarding the cache
entry if it has been truncated.
-Chris
bradley.d.volkin@intel.com July 9, 2014, 3:59 p.m. UTC | #5
On Wed, Jul 09, 2014 at 08:30:08AM -0700, Chris Wilson wrote:
> On Wed, Jul 09, 2014 at 08:10:47AM -0700, Volkin, Bradley D wrote:
> > On Wed, Jul 09, 2014 at 12:37:08AM -0700, Chris Wilson wrote:
> > > On Tue, Jul 08, 2014 at 03:26:36PM -0700, bradley.d.volkin@intel.com wrote:
> > > > From: Brad Volkin <bradley.d.volkin@intel.com>
> > > > 
> > > > This adds a small module for managing a pool of batch buffers.
> > > > The only current use case is for the command parser, as described
> > > > in the kerneldoc in the patch. The code is simple, but separating
> > > > it out makes it easier to change the underlying algorithms and to
> > > > extend to future use cases should they arise.
> > > > 
> > > > The interface is simple: init to create an empty pool, fini to
> > > > clean it up; get to obtain a new buffer, put to return it to the
> > > > pool. Note that all buffers must be returned to the pool before
> > > > freeing it.
> > > > 
> > > > Buffers are purgeable while in the pool, but not explicitly
> > > > truncated in order to avoid overhead during execbuf.
> > > > 
> > > > Locking is currently based on the caller holding the struct_mutex.
> > > > We already do that in the places where we will use the batch pool
> > > > for the command parser.
> > > > 
> > > > v2:
> > > > - s/BUG_ON/WARN_ON/ for locking assertions
> > > > - Remove the cap on pool size
> > > > - Switch from alloc/free to init/fini
> > > 
> > > You are missing the madvise mechanics.
> > 
> > _get() and _put() set obj->madv, which I thought was enough for what I've
> > described (i.e. purgeable while in the pool but not explicitly truncated).
> > Is that not enough for the shrinker to truncate as needed? Or do you want
> > them explicitly truncated while in the pool? I was worried about the extra
> > cost of getting the backing storage back during execbuf.
> 
> You need to check that the shrinker hasn't truncated your backing
> storage whilst it was marked DONTNEED. It just amounts to checking for
> obj->madv == __I915_MADV_PURGED in pool_get() and discarding the cache
> entry if it has been truncated.

Ok. When we hit a purged object, do you think it's worth doing a retry loop (as
in libdrm's cache) or just fall straight through to allocating a new object?

Brad

> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre
Chris Wilson July 9, 2014, 4:04 p.m. UTC | #6
On Wed, Jul 09, 2014 at 08:59:29AM -0700, Volkin, Bradley D wrote:
> On Wed, Jul 09, 2014 at 08:30:08AM -0700, Chris Wilson wrote:
> > You need to check that the shrinker hasn't truncated your backing
> > storage whilst it was marked DONTNEED. It just amounts to checking for
> > obj->madv == __I915_MADV_PURGED in pool_get() and discarding the cache
> > entry if it has been truncated.
> 
> Ok. When we hit a purged object, do you think it's worth doing a retry loop (as
> in libdrm's cache) or just fall straight through to allocating a new object?

I'd keeping going through the cache, deleting purged entries until we
find a usable object (or we have cleared the list).
-Chris
diff mbox

Patch

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 4890d94..2749555 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3945,6 +3945,11 @@  int num_ioctls;</synopsis>
 !Pdrivers/gpu/drm/i915/i915_cmd_parser.c batch buffer command parser
 !Idrivers/gpu/drm/i915/i915_cmd_parser.c
       </sect2>
+      <sect2>
+        <title>Batchbuffer Pools</title>
+!Pdrivers/gpu/drm/i915/i915_gem_batch_pool.c batch pool
+!Idrivers/gpu/drm/i915/i915_gem_batch_pool.c
+      </sect2>
     </sect1>
   </chapter>
 </part>
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index cad1683..b92fbe6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -17,6 +17,7 @@  i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
 
 # GEM code
 i915-y += i915_cmd_parser.o \
+	  i915_gem_batch_pool.o \
 	  i915_gem_context.o \
 	  i915_gem_render_state.o \
 	  i915_gem_debug.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 90216bb..a478a96 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1062,6 +1062,12 @@  struct intel_l3_parity {
 	int which_slice;
 };
 
+struct i915_gem_batch_pool {
+	struct drm_device *dev;
+	struct list_head active_list;
+	struct list_head inactive_list;
+};
+
 struct i915_gem_mm {
 	/** Memory allocator for GTT stolen memory */
 	struct drm_mm stolen;
@@ -1690,6 +1696,8 @@  struct drm_i915_gem_object {
 	/** Used in execbuf to temporarily hold a ref */
 	struct list_head obj_exec_link;
 
+	struct list_head batch_pool_list;
+
 	/**
 	 * This is set if the object is on the active lists (has pending
 	 * rendering and so a non-zero seqno), and is not set if it i s on
@@ -2594,6 +2602,15 @@  void i915_destroy_error_state(struct drm_device *dev);
 void i915_get_extra_instdone(struct drm_device *dev, uint32_t *instdone);
 const char *i915_cache_level_str(int type);
 
+/* i915_gem_batch_pool.c */
+void i915_gem_batch_pool_init(struct drm_device *dev,
+			      struct i915_gem_batch_pool *pool);
+void i915_gem_batch_pool_fini(struct i915_gem_batch_pool *pool);
+struct drm_i915_gem_object*
+i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool, size_t size);
+void i915_gem_batch_pool_put(struct i915_gem_batch_pool *pool,
+			     struct drm_i915_gem_object *obj);
+
 /* i915_cmd_parser.c */
 int i915_cmd_parser_get_version(void);
 int i915_cmd_parser_init_ring(struct intel_engine_cs *ring);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e5d4d73..89a4ec0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4332,6 +4332,7 @@  void i915_gem_object_init(struct drm_i915_gem_object *obj,
 	INIT_LIST_HEAD(&obj->ring_list);
 	INIT_LIST_HEAD(&obj->obj_exec_link);
 	INIT_LIST_HEAD(&obj->vma_list);
+	INIT_LIST_HEAD(&obj->batch_pool_list);
 
 	obj->ops = ops;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
new file mode 100644
index 0000000..542477f
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -0,0 +1,133 @@ 
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "i915_drv.h"
+
+/**
+ * DOC: batch pool
+ *
+ * In order to submit batch buffers as 'secure', the software command parser
+ * must ensure that a batch buffer cannot be modified after parsing. It does
+ * this by copying the user provided batch buffer contents to a kernel owned
+ * buffer from which the hardware will actually execute, and by carefully
+ * managing the address space bindings for such buffers.
+ *
+ * The batch pool framework provides a mechanism for the driver to manage a
+ * set of scratch buffers to use for this purpose. The framework can be
+ * extended to support other uses cases should they arise.
+ */
+
+/**
+ * i915_gem_batch_pool_init() - initialize a batch buffer pool
+ * @dev: the drm device
+ * @pool: the batch buffer pool
+ */
+void i915_gem_batch_pool_init(struct drm_device *dev,
+			      struct i915_gem_batch_pool *pool)
+{
+	pool->dev = dev;
+	INIT_LIST_HEAD(&pool->active_list);
+	INIT_LIST_HEAD(&pool->inactive_list);
+}
+
+/**
+ * i915_gem_batch_pool_fini() - clean up a batch buffer pool
+ * @pool: the pool to clean up
+ *
+ * Note: Callers must hold the struct_mutex. Callers must also ensure
+ *       that all buffers have been returned to the pool.
+ */
+void i915_gem_batch_pool_fini(struct i915_gem_batch_pool *pool)
+{
+	struct drm_i915_gem_object *obj, *next;
+
+	WARN_ON(!mutex_is_locked(&pool->dev->struct_mutex));
+	WARN_ON(!list_empty(&pool->active_list));
+
+	list_for_each_entry_safe(obj, next,
+				 &pool->inactive_list, batch_pool_list) {
+		list_del(&obj->batch_pool_list);
+		drm_gem_object_unreference(&obj->base);
+	}
+}
+
+/**
+ * i915_gem_batch_pool_get() - select a buffer from the pool
+ * @pool: the batch buffer pool
+ * @size: the minimum desired size of the returned buffer
+ *
+ * Finds or allocates a batch buffer in the pool with at least the requested
+ * size. The buffer will not be used to satisfy further
+ * i915_gem_batch_pool_get() requests until the corresponding
+ * i915_gem_batch_pool_put() call. The caller is responsible for any domain or
+ * active/inactive management for the returned buffer.
+ *
+ * Note: Callers must hold the struct_mutex
+ *
+ * Return: the selected batch buffer object
+ */
+struct drm_i915_gem_object *
+i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
+			size_t size)
+{
+	struct drm_i915_gem_object *obj = NULL;
+	struct drm_i915_gem_object *tmp;
+
+	WARN_ON(!mutex_is_locked(&pool->dev->struct_mutex));
+
+	list_for_each_entry(tmp, &pool->inactive_list, batch_pool_list) {
+		if (tmp->base.size >= size) {
+			obj = tmp;
+			break;
+		}
+	}
+
+	if (!obj) {
+		obj = i915_gem_alloc_object(pool->dev, size);
+		if (!obj)
+			return ERR_PTR(-ENOMEM);
+
+		list_add_tail(&obj->batch_pool_list, &pool->inactive_list);
+	}
+
+	obj->madv = I915_MADV_WILLNEED;
+	list_move_tail(&obj->batch_pool_list, &pool->active_list);
+
+	return obj;
+}
+
+/**
+ * i915_gem_batch_pool_put() - return a buffer to the pool
+ * @pool: the batch buffer pool
+ * @obj: the batch buffer object
+ *
+ * Note: Callers must hold the struct_mutex
+ */
+void i915_gem_batch_pool_put(struct i915_gem_batch_pool *pool,
+			     struct drm_i915_gem_object *obj)
+{
+	WARN_ON(!mutex_is_locked(&pool->dev->struct_mutex));
+	obj->madv = I915_MADV_DONTNEED;
+	list_move_tail(&obj->batch_pool_list, &pool->inactive_list);
+}