On 30/09/2025 18:29, Boris Brezillon wrote:
On Tue, 30 Sep 2025 18:09:37 +0200
Loïc Molinari <[email protected]> wrote:
On 30/09/2025 12:30, Boris Brezillon wrote:
On Mon, 29 Sep 2025 22:03:10 +0200
Loïc Molinari <[email protected]> wrote:
+unsigned long drm_gem_get_unmapped_area(struct file *filp, unsigned long uaddr,
+ unsigned long len, unsigned long pgoff,
+ unsigned long flags)
+{
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+ struct drm_gem_object *obj;
+ unsigned long ret;
+
+ obj = drm_gem_object_lookup_from_offset(filp, pgoff, len >> PAGE_SHIFT);
+ if (IS_ERR(obj))
+ return mm_get_unmapped_area(current->mm, filp, uaddr, len, 0,
+ flags);
+
+ ret = shmem_get_unmapped_area(obj->filp, uaddr, len, 0, flags);
+
+ drm_gem_object_put(obj);
+
+ return ret;
+#else
+ return mm_get_unmapped_area(current->mm, filp, uaddr, len, 0, flags);
Looks like the above code covers the non-THP case too, do we really need
to specialize for !CONFIG_TRANSPARENT_HUGEPAGE here?
It does cover the !CONFIG_TRANSPARENT_HUGEPAGE case
(shmem_get_unmapped_area() would just call and return the
mm_get_unmapped_area() address) but the idea here is to avoid the GEM
object lookup cost by calling mm_get_unmapped_area() directly.
I'd expect the extra GEM lookup to be negligible compared to the overall
mmap() operation to be honest, but I guess if we really want to avoid
the overhead, we could still write it without this ifdef.
if (!IS_ENABLED(TRANSPARENT_HUGEPAGE))
return mm_get_unmapped_area(current->mm, filp, uaddr,
len, 0, flags);
...
My main concern is that shmem_get_unmapped_area() evolves with more
!TRANSPARENT_HUGEPAGE cases, and by calling mm_get_unmapped_area()
directly, we miss the opportunity to get optimizations for these cases,
just like we missed them by not forwarding the ->get_unmapped_area()
requests to the shmem layer so far.
Yes, sounds like a very good point. I'll remove the ifdef and forward to
the shmem layer unconditionally.
+#endif
+}
+EXPORT_SYMBOL(drm_gem_get_unmapped_area);
Loïc
