Quoting Chris Wilson (2018-05-13 10:50:08)
> Searching for an available hole by address is slow, as there no
> guarantee that a hole will be available and so we must walk over all
> nodes in the rbtree before we determine the search was futile. In many
> cases, the caller doesn't strictly care for the highest available hole
> and was just opportunistically laying out the address space in a
> preferred order. In such cases, the caller can accept any address and
> would rather do so then do a slow walk.
>
> To be able to mix search strategies, the caller wants to tell the drm_mm
> how long to spend on the search. Without a good guide for what should be
> the best split, start with a request to try once at most. That is return
> the top-most (or lowest) hole if it fulfils the alignment and size
> requirements.
>
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
<SNIP>
> +++ b/include/drm/drm_mm.h
> @@ -109,6 +109,10 @@ enum drm_mm_insert_mode {
> * Allocates the node from the bottom of the found hole.
> */
> DRM_MM_INSERT_EVICT,
> +
Could definitely use a comment here.
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
Regards, Joonas
> + DRM_MM_INSERT_END = BIT(31),
> + DRM_MM_INSERT_HIGHEST = DRM_MM_INSERT_HIGH | DRM_MM_INSERT_END,
> + DRM_MM_INSERT_LOWEST = DRM_MM_INSERT_LOW | DRM_MM_INSERT_END,
> };
>
> /**
> --
> 2.17.0
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
