| Message ID | 20180513075010.23275-2-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@chris-wilson.co.uk> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> <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@linux.intel.com> 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 >
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index 7b4ad05fe1c0..b8e99e2a7c34 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -480,6 +480,7 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm, { struct drm_mm_node *hole; u64 remainder_mask; + bool once; DRM_MM_BUG_ON(range_start >= range_end); @@ -492,9 +493,13 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm, if (alignment <= 1) alignment = 0; + once = mode & DRM_MM_INSERT_END; + mode &= ~DRM_MM_INSERT_END; + remainder_mask = is_power_of_2(alignment) ? alignment - 1 : 0; - for (hole = first_hole(mm, range_start, range_end, size, mode); hole; - hole = next_hole(mm, hole, mode)) { + for (hole = first_hole(mm, range_start, range_end, size, mode); + hole; + hole = once ? NULL : next_hole(mm, hole, mode)) { u64 hole_start = __drm_mm_hole_node_start(hole); u64 hole_end = hole_start + hole->hole_size; u64 adj_start, adj_end; diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h index e3aa3bfd4860..2a6351093d15 100644 --- a/include/drm/drm_mm.h +++ 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, + + 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, }; /**
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@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> --- drivers/gpu/drm/drm_mm.c | 9 +++++++-- include/drm/drm_mm.h | 4 ++++ 2 files changed, 11 insertions(+), 2 deletions(-)