drm/i915: Make the kmem slab for i915_buddy_block a global
authorJason Ekstrand <jason@jlekstrand.net>
Wed, 21 Jul 2021 15:23:58 +0000 (10:23 -0500)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Thu, 22 Jul 2021 10:08:12 +0000 (12:08 +0200)
commit0f4651359a235a702b383076fc2ccbd90d9bedb4
tree8b29aa4ebdbe91bb2c7cc747a2d554ed6738459d
parenta04ea6ae7c6728cd834709f3477e75d4f74583da
drm/i915: Make the kmem slab for i915_buddy_block a global

There's no reason that I can tell why this should be per-i915_buddy_mm
and doing so causes KMEM_CACHE to throw dmesg warnings because it tries
to create a debugfs entry with the name i915_buddy_block multiple times.
We could handle this by carefully giving each slab its own name but that
brings its own pain because then we have to store that string somewhere
and manage the lifetimes of the different slabs.  The most likely
outcome would be a global atomic which we increment to get a new name or
something like that.

The much easier solution is to use the i915_globals system like we do
for every other slab in i915.  This ensures that we have exactly one of
them for each i915 driver load and it gets neatly created on module load
and destroyed on module unload.  Using the globals system also means
that its now tied into the shrink handler so we can properly respond to
low-memory situations.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Fixes: 88be9a0a06b7 ("drm/i915/ttm: add ttm_buddy_man")
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Christian König <christian.koenig@amd.com>
[danvet: Rebase against removal of global shrink code]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210721152358.2893314-7-jason@jlekstrand.net
drivers/gpu/drm/i915/i915_buddy.c
drivers/gpu/drm/i915/i915_buddy.h
drivers/gpu/drm/i915/i915_globals.c