| Message ID | 1404858400-18879-4-git-send-email-bradley.d.volkin@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jul 08, 2014 at 03:26:38PM -0700, bradley.d.volkin@intel.com wrote: > From: Brad Volkin <bradley.d.volkin@intel.com> > > It provides some useful information about the buffers in > the global command parser batch pool. > > v2: rebase on global pool instead of per-ring pools Include the counts in i915_gem_objects as well. The issue is that the kernel allocated objects will perturb the number of objects allocated (possibly substantially) so having the kernel listed for its consumption will help track usage. -Chris
On Wed, Jul 09, 2014 at 12:36:38AM -0700, Chris Wilson wrote: > On Tue, Jul 08, 2014 at 03:26:38PM -0700, bradley.d.volkin@intel.com wrote: > > From: Brad Volkin <bradley.d.volkin@intel.com> > > > > It provides some useful information about the buffers in > > the global command parser batch pool. > > > > v2: rebase on global pool instead of per-ring pools > > Include the counts in i915_gem_objects as well. > > The issue is that the kernel allocated objects will perturb the number > of objects allocated (possibly substantially) so having the kernel > listed for its consumption will help track usage. Ok, so maybe reuse per_file_stats() and add another line like those but for the batch pool? Brad > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre
On Wed, Jul 09, 2014 at 08:56:31AM -0700, Volkin, Bradley D wrote: > On Wed, Jul 09, 2014 at 12:36:38AM -0700, Chris Wilson wrote: > > On Tue, Jul 08, 2014 at 03:26:38PM -0700, bradley.d.volkin@intel.com wrote: > > > From: Brad Volkin <bradley.d.volkin@intel.com> > > > > > > It provides some useful information about the buffers in > > > the global command parser batch pool. > > > > > > v2: rebase on global pool instead of per-ring pools > > > > Include the counts in i915_gem_objects as well. > > > > The issue is that the kernel allocated objects will perturb the number > > of objects allocated (possibly substantially) so having the kernel > > listed for its consumption will help track usage. > > Ok, so maybe reuse per_file_stats() and add another line like those but > for the batch pool? Yes, something along those lines so the kernel batch pool just appears like another client. An exercise for another day would be to add a line for the other fixed entries, getting context objects accounted correctly, etc. -Chris
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index b3b56c4..696eb98 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -568,6 +568,46 @@ static int i915_gem_pageflip_info(struct seq_file *m, void *data) return 0; } +static int i915_gem_batch_pool_info(struct seq_file *m, void *data) +{ + struct drm_info_node *node = m->private; + struct drm_device *dev = node->minor->dev; + struct drm_i915_private *dev_priv = dev->dev_private; + struct drm_i915_gem_object *obj; + int count = 0; + int ret; + + ret = mutex_lock_interruptible(&dev->struct_mutex); + if (ret) + return ret; + + seq_puts(m, "active:\n"); + list_for_each_entry(obj, + &dev_priv->mm.batch_pool.active_list, + batch_pool_list) { + seq_puts(m, " "); + describe_obj(m, obj); + seq_putc(m, '\n'); + count++; + } + + seq_puts(m, "inactive:\n"); + list_for_each_entry(obj, + &dev_priv->mm.batch_pool.inactive_list, + batch_pool_list) { + seq_puts(m, " "); + describe_obj(m, obj); + seq_putc(m, '\n'); + count++; + } + + seq_printf(m, "total: %d\n", count); + + mutex_unlock(&dev->struct_mutex); + + return 0; +} + static int i915_gem_request_info(struct seq_file *m, void *data) { struct drm_info_node *node = m->private; @@ -3950,6 +3990,7 @@ static const struct drm_info_list i915_debugfs_list[] = { {"i915_gem_hws_blt", i915_hws_info, 0, (void *)BCS}, {"i915_gem_hws_bsd", i915_hws_info, 0, (void *)VCS}, {"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS}, + {"i915_gem_batch_pool", i915_gem_batch_pool_info, 0}, {"i915_rstdby_delays", i915_rstdby_delays, 0}, {"i915_frequency_info", i915_frequency_info, 0}, {"i915_delayfreq_table", i915_delayfreq_table, 0},