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@xxxxxxxxx> > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
