From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEF0F22422B for ; Tue, 30 Sep 2025 16:42:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759250533; cv=none; b=PreahMqEBZdifBLku21esnBFX3CUCzINHAasyI+glNnYfyfaZ6ceXh4eLKecs2cwT+5d9H9FFIJT/KMiwOyCYOq0S/cUop4m6SRiGG/t0IOjUky6FWFt6GEQ75klK/kZJzumnmlAJDy5iCqap8a/yUYE4sThZ2A2GSCi66Ao2wA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759250533; c=relaxed/simple; bh=jguk/JSzmwgQx5dX/LxO/aT6uGm3rPlRw2544tHroQM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ZDNrM0BxBiwuDgjgsrvkcf5tzgT3WAUwsqftNQjMbLDzRmEZnk0TnojK8akBUryCZTCAeMhW+Jqwb6jTor3IVKW2fAduWWXKHVwXbZV75bKz2+DSvYsH7L9vcuijAopmnF4Ao8GJZOV2ltDYHRsztWZWDpANoK/pek+hciilNSk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=UprHlYym; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="UprHlYym" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1759250528; bh=jguk/JSzmwgQx5dX/LxO/aT6uGm3rPlRw2544tHroQM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=UprHlYymrE1wHFS94X2ZBnAUqm9aNsgUCUOlzig/pmQXcpAZ73A3Tia1Of5aWIe/p Hg6srSyneiERMdMKwL2Y70gerM0fbtzNW/3HL7F6MAP8JfZHU6TRCVLm5OFrVNyybG DKagN9kmi2XMl3lrd9fOpVr4GPY19suaQx5YD7eZLhC/AoIRn55lPgn7URWj85tdgT FlZjWRtPVV1NbTxi3bU8xIMoqMJrDPuN8WhViUSo2Zou+lipclEuJQ0wk/BggPaGj/ jxG4pvjhJDrMM7ZDNe28fy37ZyOBz6XpB8EMOasW6BybaQnWWvrspuOTSdF/c5ja3i eVBNN3HKTsNKA== Received: from [IPV6:2a01:e0a:5e3:6100:7aed:fe0e:8590:cbaa] (unknown [IPv6:2a01:e0a:5e3:6100:7aed:fe0e:8590:cbaa]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: loicmolinari) by bali.collaboradmins.com (Postfix) with ESMTPSA id 07CFC17E010B; Tue, 30 Sep 2025 18:42:07 +0200 (CEST) Message-ID: <22680961-1a51-469a-93df-ee9a63b3fd66@collabora.com> Date: Tue, 30 Sep 2025 18:42:07 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/8] drm/gem: Introduce drm_gem_get_unmapped_area() fop To: Boris Brezillon Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , Rob Herring , Steven Price , Liviu Dudau , Melissa Wen , =?UTF-8?Q?Ma=C3=ADra_Canal?= , Hugh Dickins , Baolin Wang , Andrew Morton , Al Viro , =?UTF-8?Q?Miko=C5=82aj_Wasiak?= , Christian Brauner , Nitin Gote , Andi Shyti , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, linux-mm@kvack.org, kernel@collabora.com References: <20250929200316.18417-1-loic.molinari@collabora.com> <20250929200316.18417-3-loic.molinari@collabora.com> <20250930123003.75370854@fedora> <20250930182920.5604ca49@fedora> Content-Language: fr From: =?UTF-8?Q?Lo=C3=AFc_Molinari?= Organization: Collabora Ltd In-Reply-To: <20250930182920.5604ca49@fedora> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 30/09/2025 18:29, Boris Brezillon wrote: > On Tue, 30 Sep 2025 18:09:37 +0200 > Loïc Molinari wrote: > >> On 30/09/2025 12:30, Boris Brezillon wrote: >>> On Mon, 29 Sep 2025 22:03:10 +0200 >>> >>> Loïc Molinari 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 >