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>
Showing
Please register or sign in to comment