On Thu, Dec 6, 2012 at 4:25 PM, Daniel Vetter daniel@ffwll.ch wrote:
On Thu, Dec 6, 2012 at 3:54 PM, Chris Wilson chris@chris-wilson.co.uk wrote:
As the shrinker may be invoked for the allocation, and it may reap neighbouring objects in the offset range mm, we need to be careful in the order in which we allocate the node, search for free space and then insert the node into the mmap offset range manager.
Signed-off-by: Chris Wilson chris@chris-wilson.co.uk Cc: Dave Airlie airlied@redhat.com Cc: dri-devel@lists.freedesktop.org
I think leaking allocation/shrinker details from drm/i915 like that into common (helper) code is a no-go. Which means we need to open-code create_mmap_offset in our code and add a big comment ...
Otoh killing the 2-step drm_mm node allocation process with search_free and get_block has been on my todo since forever. Especially since it doesn't add any useful flexibility, but makes preallocation schemes much more likely to be broken. See this patch, or what ttm tries to accomplish (with the broken prealloc helpers in drm_mm.c).
So reconsidering this patch it's
Reviewed-by: Daniel Vetter daniel@ffwll.ch
But not exactly for the reasons listed in the commit message ;-)
Cheers, Daniel