[PATCH 2/2] drm/mm: improve rb_hole_addr rbtree search

[Nirmoy]

Hi Chris,

On 5/20/20 12:56 AM, Chris Wilson wrote:
> Quoting Nirmoy Das (2020-05-19 09:44:36)
>> +#define DRM_MM_ALIGN_SHIFT 6
>>   #define HOLE_SIZE(NODE) ((NODE)->hole_size)
>>   #define HOLE_ADDR(NODE) (__drm_mm_hole_node_start(NODE))
>> +#define HOLE_SIZE_ALIGN(NODE) ((NODE->hole_size << DRM_MM_ALIGN_SHIFT) | \
>> +                              ffs(HOLE_ADDR(NODE)))
> Fwiw, max hole size of 58b, we would need to stop storing byte
> extents...


Can you please explain 2nd part of this statement.


>>   static struct drm_mm_node *
>> -next_hole_low_addr(struct drm_mm_node *entry, u64 size)
>> +next_hole_low_addr(struct drm_mm_node *entry, u64 size, u64 alignment)
>>   {
>>          struct rb_node *rb_node, *right_rb_node, *parent_rb_node;
>>          struct drm_mm_node *right_node;
>> +       u64 req_align = (size + alignment) << DRM_MM_ALIGN_SHIFT;
>>   
>>          if (!entry)
>>                  return NULL;
>> @@ -513,6 +561,7 @@ next_hole_low_addr(struct drm_mm_node *entry, u64 size)
>>                  right_node = rb_entry(right_rb_node,
>>                                        struct drm_mm_node, rb_hole_addr);
>>                  if ((right_node->subtree_max_hole < size ||
>> +                    right_node->subtree_max_hole_align < req_align ||
> What was the point in storing the packed alignment if we are just
> searching for a hole big enough for (size + alignment)?

Yes, I realized this is not correct :/

Still thinking about a better solution to capture alignment into subtree 
elimination.


Regards,

Nirmoy

> -Chris
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cnirmoy.das%40amd.com%7C1b1ab9c2ca03412daa2108d7fc47d26e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255257724473951&sdata=gDRvdhwLV1M%2BKLCgpENik52gAB3O0ik1n%2B%2FaZxLgr%2Fk%3D&reserved=0