[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <22680961-1a51-469a-93df-ee9a63b3fd66@collabora.com>
Date: Tue, 30 Sep 2025 18:42:07 +0200
From: Loïc Molinari <loic.molinari@...labora.com>
To: Boris Brezillon <boris.brezillon@...labora.com>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>, Tvrtko Ursulin
<tursulin@...ulin.net>, Rob Herring <robh@...nel.org>,
Steven Price <steven.price@....com>, Liviu Dudau <liviu.dudau@....com>,
Melissa Wen <mwen@...lia.com>, Maíra Canal
<mcanal@...lia.com>, Hugh Dickins <hughd@...gle.com>,
Baolin Wang <baolin.wang@...ux.alibaba.com>,
Andrew Morton <akpm@...ux-foundation.org>, Al Viro
<viro@...iv.linux.org.uk>, Mikołaj Wasiak
<mikolaj.wasiak@...el.com>, Christian Brauner <brauner@...nel.org>,
Nitin Gote <nitin.r.gote@...el.com>, Andi Shyti
<andi.shyti@...ux.intel.com>, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org,
linux-mm@...ck.org, kernel@...labora.com
Subject: Re: [PATCH 2/8] drm/gem: Introduce drm_gem_get_unmapped_area() fop
On 30/09/2025 18:29, Boris Brezillon wrote:
> On Tue, 30 Sep 2025 18:09:37 +0200
> Loïc Molinari <loic.molinari@...labora.com> wrote:
>
>> On 30/09/2025 12:30, Boris Brezillon wrote:
>>> On Mon, 29 Sep 2025 22:03:10 +0200
>>>
>>> Loïc Molinari <loic.molinari@...labora.com> 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
>
Powered by blists - more mailing lists