From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Vivek Kasireddy <vivek.kasireddy@intel.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation
Date: Wed, 2 Feb 2022 13:04:16 +0000 [thread overview]
Message-ID: <ed22efe9-4cd8-cf71-beb7-66af7161c518@linux.intel.com> (raw)
In-Reply-To: <20220202011358.1409946-1-vivek.kasireddy@intel.com>
On 02/02/2022 01:13, Vivek Kasireddy wrote:
> This iterator relies on drm_mm_first_hole() and drm_mm_next_hole()
> functions to identify suitable holes for an allocation of a given
> size by efficently traversing the rbtree associated with the given
> allocator.
>
> It replaces the for loop in drm_mm_insert_node_in_range() and can
> also be used by drm drivers to quickly identify holes of a certain
> size within a given range.
>
> Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
> drivers/gpu/drm/drm_mm.c | 28 ++++++++++++----------------
> include/drm/drm_mm.h | 32 ++++++++++++++++++++++++++++++++
> 2 files changed, 44 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index 8257f9d4f619..416c849c10e5 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -352,10 +352,10 @@ static struct drm_mm_node *find_hole_addr(struct drm_mm *mm, u64 addr, u64 size)
> return node;
> }
>
> -static struct drm_mm_node *
> -first_hole(struct drm_mm *mm,
> - u64 start, u64 end, u64 size,
> - enum drm_mm_insert_mode mode)
> +struct drm_mm_node *
> +drm_mm_first_hole(struct drm_mm *mm,
> + u64 start, u64 end, u64 size,
> + enum drm_mm_insert_mode mode)
> {
> switch (mode) {
> default:
> @@ -374,6 +374,7 @@ first_hole(struct drm_mm *mm,
> hole_stack);
> }
> }
> +EXPORT_SYMBOL(drm_mm_first_hole);
>
> /**
> * DECLARE_NEXT_HOLE_ADDR - macro to declare next hole functions
> @@ -410,11 +411,11 @@ static struct drm_mm_node *name(struct drm_mm_node *entry, u64 size) \
> DECLARE_NEXT_HOLE_ADDR(next_hole_high_addr, rb_left, rb_right)
> DECLARE_NEXT_HOLE_ADDR(next_hole_low_addr, rb_right, rb_left)
>
> -static struct drm_mm_node *
> -next_hole(struct drm_mm *mm,
> - struct drm_mm_node *node,
> - u64 size,
> - enum drm_mm_insert_mode mode)
> +struct drm_mm_node *
> +drm_mm_next_hole(struct drm_mm *mm,
> + struct drm_mm_node *node,
> + u64 size,
> + enum drm_mm_insert_mode mode)
> {
> switch (mode) {
> default:
> @@ -432,6 +433,7 @@ next_hole(struct drm_mm *mm,
> return &node->hole_stack == &mm->hole_stack ? NULL : node;
> }
> }
> +EXPORT_SYMBOL(drm_mm_next_hole);
May need to add kerneldoc since first/next_hole are now exported, or
perhaps double underscore them if DRM core allows that approach to kind
of signify "it is exported by shouldn't really be used"? Question for
dri-devel I guess.
>
> /**
> * drm_mm_reserve_node - insert an pre-initialized node
> @@ -520,7 +522,6 @@ 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);
>
> @@ -533,13 +534,8 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
> if (alignment <= 1)
> alignment = 0;
>
> - once = mode & DRM_MM_INSERT_ONCE;
> - mode &= ~DRM_MM_INSERT_ONCE;
> -
> remainder_mask = is_power_of_2(alignment) ? alignment - 1 : 0;
> - for (hole = first_hole(mm, range_start, range_end, size, mode);
> - hole;
> - hole = once ? NULL : next_hole(mm, hole, size, mode)) {
> + drm_mm_for_each_best_hole(hole, mm, range_start, range_end, size, 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 ac33ba1b18bc..5055447697fa 100644
> --- a/include/drm/drm_mm.h
> +++ b/include/drm/drm_mm.h
> @@ -322,6 +322,17 @@ static inline u64 __drm_mm_hole_node_end(const struct drm_mm_node *hole_node)
> return list_next_entry(hole_node, node_list)->start;
> }
>
> +struct drm_mm_node *
> +drm_mm_first_hole(struct drm_mm *mm,
> + u64 start, u64 end, u64 size,
> + enum drm_mm_insert_mode mode);
> +
> +struct drm_mm_node *
> +drm_mm_next_hole(struct drm_mm *mm,
> + struct drm_mm_node *node,
> + u64 size,
> + enum drm_mm_insert_mode mode);
> +
> /**
> * drm_mm_hole_node_end - computes the end of the hole following @node
> * @hole_node: drm_mm_node which implicitly tracks the following hole
> @@ -400,6 +411,27 @@ static inline u64 drm_mm_hole_node_end(const struct drm_mm_node *hole_node)
> 1 : 0; \
> pos = list_next_entry(pos, hole_stack))
>
> +/**
> + * drm_mm_for_each_best_hole - iterator to optimally walk over all holes >= @size
> + * @pos: &drm_mm_node used internally to track progress
> + * @mm: &drm_mm allocator to walk
> + * @range_start: start of the allowed range for the allocation
> + * @range_end: end of the allowed range for the allocation
> + * @size: size of the allocation
> + * @mode: fine-tune the allocation search
> + *
> + * This iterator walks over all holes suitable for the allocation of given
> + * @size in a very efficient manner. It is implemented by calling
> + * drm_mm_first_hole() and drm_mm_next_hole() which identify the
> + * appropriate holes within the given range by efficently traversing the
> + * rbtree associated with @mm.
> + */
> +#define drm_mm_for_each_best_hole(pos, mm, range_start, range_end, size, mode) \
Probably should not have "best" in the name since the mode is passed in
by the caller.
> + for (pos = drm_mm_first_hole(mm, range_start, range_end, size, mode); \
> + pos; \
> + pos = mode & DRM_MM_INSERT_ONCE ? \
> + NULL : drm_mm_next_hole(mm, hole, size, mode))
I think you would need to modify the first/next_hole to mask out
DRM_MM_INSERT_ONCE, otherwise it probably does not work as it stands.
Regards,
Tvrtko
> +
> /*
> * Basic range manager support (drm_mm.c)
> */
next prev parent reply other threads:[~2022-02-02 13:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-02 1:13 [PATCH 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation Vivek Kasireddy
2022-02-02 13:04 ` Tvrtko Ursulin [this message]
2022-02-03 9:08 ` Kasireddy, Vivek
2022-02-04 1:19 ` [Intel-gfx] [PATCH 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation (v2) Vivek Kasireddy
2022-02-04 1:19 ` Vivek Kasireddy
2022-02-07 10:45 ` [Intel-gfx] " Tvrtko Ursulin
2022-02-07 10:45 ` Tvrtko Ursulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ed22efe9-4cd8-cf71-beb7-66af7161c518@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=vivek.kasireddy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.