On Thu, Dec 6, 2012 at 4:25 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Thu, Dec 6, 2012 at 3:54 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> >> Cc: Dave Airlie <airlied@xxxxxxxxxx> >> Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxx> But not exactly for the reasons listed in the commit message ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
