[Intel-gfx] [PATCH 1/3] drm/i915: buddy allocator

[Chris Wilson]

Quoting Matthew Auld (2019-08-09 21:29:24)
> Simple buddy allocator. We want to allocate properly aligned
> power-of-two blocks to promote usage of huge-pages for the GTT, so 64K,
> 2M and possibly even 1G. While we do support allocating stuff at a
> specific offset, it is more intended for preallocating portions of the
> address space, say for an initial framebuffer, for other uses drm_mm is
> probably a much better fit. Anyway, hopefully this can all be thrown
> away if we eventually move to having the core MM manage device memory.
> 
> Signed-off-by: Matthew Auld <matthew.auld at intel.com>
> Cc: Chris Wilson <chris at chris-wilson.co.uk>

It does what it says on the tin. Some debate over the overall motivation
of the patch, but in regards to implementing a very simple buddy
allocator that can stand amongst the many other allocations (that
unfortunately are tied to their users, despite the kernel having many
advanced allocators e.g. slub, none are available for managing a driver
address block -- quite a number of drivers have their own drm_mm
equivalents, including vmalloc!) it looks useful. I regard this as being
more lib/ material than anything else. Maybe once we have the eviction
schemes fleshed out, we can lift it to lib/

I would liked to have a bit more on the theory of operation (how) inside
the buddy.c and some more of the why inside the buddy.h, especially for
libification where potential users need to see if it fits, and I would
like a suite of perf metrics (builtin performance tests, supplemental
fragmentation statistics)... So I think there is a bit more work to be
done to make it suitable for lib/, i.e. something that other people will
want to use!

Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
-Chris