drm/i915: Add a tracepoint for the shrinker

Browse source

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>

...

This commit is contained in:

Chris Wilson 2015-10-01 12:18:26 +01:00 • committed by Daniel Vetter

parent cb42261997

commit 3abafa539d

2 changed files with 22 additions and 0 deletions

Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL

Download patch file Download diff file Expand all files Collapse all files

2

drivers/gpu/drm/i915/i915_gem_shrinker.c

View file

20

drivers/gpu/drm/i915/i915_trace.h

View file