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. > > >> +#endif > >> +} > >> +EXPORT_SYMBOL(drm_gem_get_unmapped_area); > > Loïc
