Oh, yeah ... I find one aspect, we need to consider "range_start" and "range_end" Yeah, you guys are right, cool /Monk -----Original Message----- From: Liu, Monk Sent: Tuesday, November 27, 2018 10:10 PM To: Koenig, Christian <Christian.Koenig@xxxxxxx>; Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>; dri-devel@xxxxxxxxxxxxxxx Subject: RE: [PATCH] drm: should return upon the best size(v3) The logic this patch change is only for "best_hole" which is only get called with " DRM_MM_INSERT_BEST", In drm_mm_insert_node_in_range(), is there other aspect also need calculation and judge for the mode " DRM_MM_INSERT_BEST" ?? /Monk -----Original Message----- From: Christian König <ckoenig.leichtzumerken@xxxxxxxxx> Sent: Tuesday, November 27, 2018 9:48 PM To: Liu, Monk <Monk.Liu@xxxxxxx>; Koenig, Christian <Christian.Koenig@xxxxxxx>; Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>; dri-devel@xxxxxxxxxxxxxxx Subject: Re: [PATCH] drm: should return upon the best size(v3) Am 27.11.18 um 14:40 schrieb Liu, Monk: >> A node with the searched size is not necessary the leftmost one, > We may have two nodes with the same size, and the one return first will be sure *not* the leftmost one, I aware of that ... > But my question is why we need the leftmost one ? Because the code is designed to iterate over all available nodes. The size is just the primary criteria to judge on. If we won't return all nodes with the same size we won't necessary find a fitting one. See how the code is used in drm_mm_insert_node_in_range(). Christian. > > > -----Original Message----- > From: Christian König <ckoenig.leichtzumerken@xxxxxxxxx> > Sent: Tuesday, November 27, 2018 8:54 PM > To: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>; Liu, Monk > <Monk.Liu@xxxxxxx>; dri-devel@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] drm: should return upon the best size(v3) > > Am 27.11.18 um 11:00 schrieb Christian König: >> Am 27.11.18 um 10:20 schrieb Chris Wilson: >>> Quoting Monk Liu (2018-11-27 03:10:34) >>>> v2: >>>> amend description: >>>> for RB tree traveler we don't need to travel to the bottom level if >>>> already found the equal size node, thus the search performance can >>>> get improved. >>>> >>>> v3: >>>> split "<=" to "<" case and "==" case >>>> >>>> Tested-by: Rex Zhu <Rex.zhu@xxxxxxx> >>>> Signed-off-by: Monk Liu <Monk.Liu@xxxxxxx> >>> Still fundamentally broken. >> Can you explain that further? Do we need to return the deepest hole >> of the right size because the following algorithm depends on that? > Ok figured it out myself by thinking more about it. > > A node with the searched size is not necessary the leftmost one, so we would not see all nodes with the searched size and potentially use the wrong one. > > Sorry Monk, but Chris is right this optimization is illegal. > > Regards, > Christian. > >> Thanks, >> Christian. >> >>> -Chris >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@xxxxxxxxxxxxxxxxxxxxx >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
