Chris Wilson 3abafa539d 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>
2015-10-07 16:05:38 +02:00
..
2015-09-26 20:54:53 -04:00
2015-09-08 16:48:55 -07:00
2015-09-04 11:35:03 -07:00
2015-09-11 16:21:12 -07:00
2015-09-27 06:45:18 -04:00
2015-09-08 14:35:59 -07:00
2015-09-03 16:41:38 -07:00
2015-09-11 16:42:39 -07:00
2015-09-08 17:22:35 -07:00
2015-09-26 20:53:15 -04:00
2015-09-08 16:33:16 -07:00
2015-09-09 11:17:33 -07:00
2015-09-25 11:16:53 -07:00
2015-09-17 21:41:02 -07:00
2015-09-09 10:55:32 -07:00
2015-09-05 19:37:31 +02:00
2015-09-18 09:28:20 -07:00
2015-09-21 12:02:27 -07:00
2015-09-26 20:56:50 -04:00
2015-09-18 09:28:20 -07:00