All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 07/15] drm/i915: Stop using obj->obj_exec_link	outside of execbuf
Date: Fri, 24 Feb 2017 14:32:13 +0200	[thread overview]
Message-ID: <871sundb1u.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20170223161830.26965-8-chris@chris-wilson.co.uk>

Chris Wilson <chris@chris-wilson.co.uk> writes:

> i915_gem_stolen_list_info() sneakily takes advantage of the
> obj->obj_exec_link to save itself from having to allocate. Enough of the
> subterfuge, just allocate an array of pointers and sort them instead of
> the list.
>

Justifiable by itself but I suspect you have plans for mutex.

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>

> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 52 ++++++++++++++++++++-----------------
>  1 file changed, 28 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index ddae8e442176..75efa1ae234e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -27,7 +27,7 @@
>   */
>  
>  #include <linux/debugfs.h>
> -#include <linux/list_sort.h>
> +#include <linux/sort.h>
>  #include "intel_drv.h"
>  
>  static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
> @@ -230,13 +230,12 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
>  		seq_printf(m, " (frontbuffer: 0x%03x)", frontbuffer_bits);
>  }
>  
> -static int obj_rank_by_stolen(void *priv,
> -			      struct list_head *A, struct list_head *B)
> +static int obj_rank_by_stolen(const void *A, const void *B)
>  {
> -	struct drm_i915_gem_object *a =
> -		container_of(A, struct drm_i915_gem_object, obj_exec_link);
> -	struct drm_i915_gem_object *b =
> -		container_of(B, struct drm_i915_gem_object, obj_exec_link);
> +	const struct drm_i915_gem_object *a =
> +		*(const struct drm_i915_gem_object **)A;
> +	const struct drm_i915_gem_object *b =
> +		*(const struct drm_i915_gem_object **)B;
>  
>  	if (a->stolen->start < b->stolen->start)
>  		return -1;
> @@ -249,49 +248,54 @@ static int i915_gem_stolen_list_info(struct seq_file *m, void *data)
>  {
>  	struct drm_i915_private *dev_priv = node_to_i915(m->private);
>  	struct drm_device *dev = &dev_priv->drm;
> +	struct drm_i915_gem_object **objects;
>  	struct drm_i915_gem_object *obj;
>  	u64 total_obj_size, total_gtt_size;
> -	LIST_HEAD(stolen);
> -	int count, ret;
> +	unsigned long count, n;
> +	int ret;
>  
>  	ret = mutex_lock_interruptible(&dev->struct_mutex);
>  	if (ret)
>  		return ret;
>  
> +	objects = drm_malloc_ab(dev_priv->mm.object_count, sizeof(*objects));
> +	if (!objects) {
> +		ret = -ENOMEM;
> +		goto out_unlock;
> +	}
> +
>  	total_obj_size = total_gtt_size = count = 0;
>  	list_for_each_entry(obj, &dev_priv->mm.bound_list, global_link) {
>  		if (obj->stolen == NULL)
>  			continue;
>  
> -		list_add(&obj->obj_exec_link, &stolen);
> -
> +		objects[count++] = obj;
>  		total_obj_size += obj->base.size;
>  		total_gtt_size += i915_gem_obj_total_ggtt_size(obj);
> -		count++;
>  	}
>  	list_for_each_entry(obj, &dev_priv->mm.unbound_list, global_link) {
>  		if (obj->stolen == NULL)
>  			continue;
>  
> -		list_add(&obj->obj_exec_link, &stolen);
> -
> +		objects[count++] = obj;
>  		total_obj_size += obj->base.size;
> -		count++;
>  	}
> -	list_sort(NULL, &stolen, obj_rank_by_stolen);
> +
> +	sort(objects, count, sizeof(*objects), obj_rank_by_stolen, NULL);
> +
>  	seq_puts(m, "Stolen:\n");
> -	while (!list_empty(&stolen)) {
> -		obj = list_first_entry(&stolen, typeof(*obj), obj_exec_link);
> +	for (n = 0; n < count; n++) {
>  		seq_puts(m, "   ");
> -		describe_obj(m, obj);
> +		describe_obj(m, objects[n]);
>  		seq_putc(m, '\n');
> -		list_del_init(&obj->obj_exec_link);
>  	}
> -	mutex_unlock(&dev->struct_mutex);
> -
> -	seq_printf(m, "Total %d objects, %llu bytes, %llu GTT size\n",
> +	seq_printf(m, "Total %lu objects, %llu bytes, %llu GTT size\n",
>  		   count, total_obj_size, total_gtt_size);
> -	return 0;
> +
> +	drm_free_large(objects);
> +out_unlock:
> +	mutex_unlock(&dev->struct_mutex);
> +	return ret;
>  }
>  
>  struct file_stats {
> -- 
> 2.11.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-02-24 12:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-23 16:18 Make execbuf fast[er] Chris Wilson
2017-02-23 16:18 ` [PATCH 01/15] drm/i915: Copy user requested buffers into the error state Chris Wilson
2017-02-28  6:11   ` Ben Widawsky
2017-02-28 14:17   ` Joonas Lahtinen
2017-02-23 16:18 ` [PATCH 02/15] drm/i915: Retire an active batch pool object rather than allocate new Chris Wilson
2017-02-23 16:18 ` [PATCH 03/15] drm/i915: Drop spinlocks around adding to the client request list Chris Wilson
2017-02-24 12:05   ` Mika Kuoppala
2017-02-23 16:18 ` [PATCH 04/15] drm/i915: Amalgamate execbuffer parameter structures Chris Wilson
2017-02-23 16:18 ` [PATCH 05/15] drm/i915: Use vma->exec_entry as our double-entry placeholder Chris Wilson
2017-02-23 16:18 ` [PATCH 06/15] drm/i915: Split vma exec_link/evict_link Chris Wilson
2017-02-24 12:20   ` Mika Kuoppala
2017-02-23 16:18 ` [PATCH 07/15] drm/i915: Stop using obj->obj_exec_link outside of execbuf Chris Wilson
2017-02-24 12:32   ` Mika Kuoppala [this message]
2017-02-23 16:18 ` [PATCH 08/15] drm/i915: Store a direct lookup from object handle to vma Chris Wilson
2017-02-23 16:18 ` [PATCH 09/15] drm/i915: Pass vma to relocate entry Chris Wilson
2017-02-23 16:18 ` [PATCH 10/15] drm/i915: Eliminate lots of iterations over the execobjects array Chris Wilson
2017-02-23 16:18 ` [PATCH 11/15] drm/i915: First try the previous execbuffer location Chris Wilson
2017-02-23 16:18 ` [PATCH 12/15] drm/i915: Wait upon userptr get-user-pages within execbuffer Chris Wilson
2017-02-24 13:53   ` Michał Winiarski
2017-02-24 14:23     ` Chris Wilson
2017-02-23 16:18 ` [PATCH 13/15] drm/i915: Remove superfluous i915_add_request_no_flush() helper Chris Wilson
2017-02-23 16:18 ` [PATCH 14/15] drm/i915: Allow execbuffer to use the first object as the batch Chris Wilson
2017-02-23 16:18 ` [PATCH 15/15] drm/i915: Async GPU relocation processing Chris Wilson

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=871sundb1u.fsf@gaia.fi.intel.com \
    --to=mika.kuoppala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.