summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/i915_gem_shrinker.c
diff options
context:
space:
mode:
authorChris Wilson <chris@chris-wilson.co.uk>2015-10-01 12:18:26 +0100
committerDaniel Vetter <daniel.vetter@ffwll.ch>2015-10-07 16:05:38 +0200
commit3abafa539d2c17d46df3f47b35eb784fdf3020a1 (patch)
tree751ea6d6485daaf248c374abb0398af4b2a770a5 /drivers/gpu/drm/i915/i915_gem_shrinker.c
parentcb422619976f3f1b71f68f0c1b5a764e9f90fb0c (diff)
drm/i915: Add a tracepoint for the shrinker
Often it is very useful to know why we suddenly purge vast tracts of memory and surprisingly up until now we didn't even have a tracepoint for when we shrink our memory. Note that there are slab_start/end tracepoints already, but those don't cover the internal recursion when we directly call into our shrinker code. Hence a separate tracepoint seems justified. Also note that we don't really need a separate tracepoint for the actual amount of pages freed since we already have an unbind tracpoint for that. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add a note that there's also slab_start/end and why they're insufficient.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'drivers/gpu/drm/i915/i915_gem_shrinker.c')
-rw-r--r--drivers/gpu/drm/i915/i915_gem_shrinker.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 858df2bffc9e..1b66e1d1def1 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -85,6 +85,8 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
}, *phase;
unsigned long count = 0;
+ trace_i915_gem_shrink(dev_priv, target, flags);
+
/*
* As we may completely rewrite the (un)bound list whilst unbinding
* (due to retiring requests) we have to strictly process only