From: "Kasireddy, Vivek" <vivek.kasireddy@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [CI 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation (v4)
Date: Mon, 28 Feb 2022 19:05:17 +0000 [thread overview]
Message-ID: <7ce7408a05c84c978af5b49351aa019b@intel.com> (raw)
In-Reply-To: <97f17df4-f820-afd4-7e48-f6f62bb9ee34@linux.intel.com>
Hi Tvrtko,
>
> Hi Vivek,
>
> On 27/02/2022 17:29, 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 efficiently 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.
> >
> > v2: (Tvrtko)
> > - Prepend a double underscore for the newly exported first/next_hole
> > - s/each_best_hole/each_suitable_hole/g
> > - Mask out DRM_MM_INSERT_ONCE from the mode before calling
> > first/next_hole and elsewhere.
> >
> > v3: (Tvrtko)
> > - Reduce the number of hunks by retaining the "mode" variable name
> >
> > v4:
> > - Typo: s/__drm_mm_next_hole(.., hole/__drm_mm_next_hole(.., pos
> >
> > Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > Acked-by: Christian König <christian.koenig@amd.com>
> > Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> > ---
> > drivers/gpu/drm/drm_mm.c | 32 +++++++++++++++-----------------
> > include/drm/drm_mm.h | 36 ++++++++++++++++++++++++++++++++++++
> > 2 files changed, 51 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> > index 8257f9d4f619..8efea548ae9f 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);
> >
> > /**
> > * drm_mm_reserve_node - insert an pre-initialized node
> > @@ -516,11 +518,11 @@ int drm_mm_insert_node_in_range(struct drm_mm * const
> mm,
> > u64 size, u64 alignment,
> > unsigned long color,
> > u64 range_start, u64 range_end,
> > - enum drm_mm_insert_mode mode)
> > + enum drm_mm_insert_mode caller_mode)
> > {
> > struct drm_mm_node *hole;
> > u64 remainder_mask;
> > - bool once;
> > + enum drm_mm_insert_mode mode = caller_mode &
> ~DRM_MM_INSERT_ONCE;
> >
> > DRM_MM_BUG_ON(range_start > range_end);
> >
> > @@ -533,13 +535,9 @@ 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_suitable_hole(hole, mm, range_start, range_end,
> > + size, mode) {
>
> I was doing one last read of the patch before I ask the maintainers
> where to merge it and realized - don't you need to pass in the
> caller_mode just here (not mode which has been masked out from "once")?
> Otherwise "once" mode will not be respected by the iterator.
[Kasireddy, Vivek] Right, yet another typo; it should have been caller_mode
instead of mode. Let me fix it and run it through another CI cycle.
Thanks,
Vivek
>
> Regards,
>
> Tvrtko
>
> > 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..dff6db627807 100644
> > --- a/include/drm/drm_mm.h
> > +++ b/include/drm/drm_mm.h
> > @@ -400,6 +400,42 @@ static inline u64 drm_mm_hole_node_end(const struct
> drm_mm_node *hole_node)
> > 1 : 0; \
> > pos = list_next_entry(pos, hole_stack))
> >
> > +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_for_each_suitable_hole - iterator to optimally walk over all
> > + * holes that can fit an allocation of the given @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 efficiently traversing the
> > + * rbtree associated with @mm.
> > + */
> > +#define drm_mm_for_each_suitable_hole(pos, mm, range_start, range_end, \
> > + size, mode) \
> > + for (pos = __drm_mm_first_hole(mm, range_start, range_end, size, \
> > + mode & ~DRM_MM_INSERT_ONCE); \
> > + pos; \
> > + pos = mode & DRM_MM_INSERT_ONCE ? \
> > + NULL : __drm_mm_next_hole(mm, pos, size, \
> > + mode & ~DRM_MM_INSERT_ONCE))
> > +
> > /*
> > * Basic range manager support (drm_mm.c)
> > */
next prev parent reply other threads:[~2022-02-28 19:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-27 17:29 [Intel-gfx] [CI 0/2] drm/mm: Add an iterator to optimally walk over holes suitable for an allocation Vivek Kasireddy
2022-02-27 17:29 ` [Intel-gfx] [CI 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation (v4) Vivek Kasireddy
2022-02-28 10:34 ` Tvrtko Ursulin
2022-02-28 19:05 ` Kasireddy, Vivek [this message]
2022-02-27 17:29 ` [Intel-gfx] [CI 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v9) Vivek Kasireddy
2022-02-27 17:57 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation Patchwork
2022-02-27 17:59 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-02-27 18:31 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-02-27 20:01 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2022-02-23 22:45 [Intel-gfx] [CI 0/2] " Vivek Kasireddy
2022-02-23 22:45 ` [Intel-gfx] [CI 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation (v4) Vivek Kasireddy
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=7ce7408a05c84c978af5b49351aa019b@intel.com \
--to=vivek.kasireddy@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=tvrtko.ursulin@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox