From: Boris Brezillon <boris.brezillon@collabora.com>
To: "Loïc Molinari" <loic.molinari@collabora.com>
Cc: "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Tvrtko Ursulin" <tursulin@ursulin.net>,
"Rob Herring" <robh@kernel.org>,
"Steven Price" <steven.price@arm.com>,
"Liviu Dudau" <liviu.dudau@arm.com>,
"Melissa Wen" <mwen@igalia.com>,
"Maíra Canal" <mcanal@igalia.com>,
"Hugh Dickins" <hughd@google.com>,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Al Viro" <viro@zeniv.linux.org.uk>,
"Mikołaj Wasiak" <mikolaj.wasiak@intel.com>,
"Christian Brauner" <brauner@kernel.org>,
"Nitin Gote" <nitin.r.gote@intel.com>,
"Andi Shyti" <andi.shyti@linux.intel.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Christopher Healy" <healych@amazon.com>,
"Matthew Wilcox" <willy@infradead.org>,
"Bagas Sanjaya" <bagasdotme@gmail.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, linux-mm@kvack.org,
linux-doc@vger.kernel.org, kernel@collabora.com
Subject: Re: [PATCH v4 08/13] drm/v3d: Fix builds with CONFIG_TRANSPARENT_HUGEPAGE=n
Date: Thu, 16 Oct 2025 07:56:37 +0200 [thread overview]
Message-ID: <20251016075637.3aec3465@fedora> (raw)
In-Reply-To: <efc1d805-1613-45a9-aa15-fcc009adf27c@collabora.com>
On Wed, 15 Oct 2025 22:41:59 +0200
Loïc Molinari <loic.molinari@collabora.com> wrote:
> On 15/10/2025 20:17, Boris Brezillon wrote:
> > On Wed, 15 Oct 2025 17:30:12 +0200
> > Loïc Molinari <loic.molinari@collabora.com> wrote:
> >
> >> Don't declare "super_pages" on builds with CONFIG_TRANSPARENT_HUGEPAGE
> >> disabled to prevent build error:
> >>
> >> ERROR: modpost: "super_pages" [drivers/gpu/drm/v3d/v3d.ko] undefined!
> >
> > I believe this is a bug introduced by the previous commit: the
> > compiler probably drops any code between the
> > IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) check and the err label
> > because IS_ENABLED() evaluates to false at compile time. So I'd squash
> > those changes in the previous commit.
>
> Right, it's been introduced in previous commit.
>
> >
> >>
> >> Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
> >> ---
> >> drivers/gpu/drm/v3d/v3d_drv.h | 2 ++
> >> drivers/gpu/drm/v3d/v3d_gem.c | 2 ++
> >> 2 files changed, 4 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
> >> index 99a39329bb85..481502104391 100644
> >> --- a/drivers/gpu/drm/v3d/v3d_drv.h
> >> +++ b/drivers/gpu/drm/v3d/v3d_drv.h
> >> @@ -564,7 +564,9 @@ extern const struct dma_fence_ops v3d_fence_ops;
> >> struct dma_fence *v3d_fence_create(struct v3d_dev *v3d, enum v3d_queue q);
> >>
> >> /* v3d_gem.c */
> >> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >> extern bool super_pages;
> >> +#endif
> >> int v3d_gem_init(struct drm_device *dev);
> >> void v3d_gem_destroy(struct drm_device *dev);
> >> void v3d_reset_sms(struct v3d_dev *v3d);
> >> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
> >> index 635ff0fabe7e..0039063eb8b2 100644
> >> --- a/drivers/gpu/drm/v3d/v3d_gem.c
> >> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> >> @@ -269,7 +269,9 @@ v3d_huge_mnt_init(struct v3d_dev *v3d)
> >> * match our usecase.
> >> */
> >>
> >> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >> if (super_pages)
> >> +#endif
> >> err = drm_gem_huge_mnt_create(&v3d->drm, "within_size");
> >
> > Why not
> >
> > #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > if (super_pages)
> > err = drm_gem_huge_mnt_create(&v3d->drm, "within_size");
> > #endif
> >
> > I guess
> >
> > if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && super_pages)
> > err = drm_gem_huge_mnt_create(&v3d->drm, "within_size");
> >
> > would also do, since it's likely to rely on the same optimization the
> > previous v3d_gemfs_init() implementation was relying on, but it's
> > fragile (not sure what happens when compiled with -O0).
>
> I'll remove the #ifdef/#endif around the super_pages declaration in
> v3d_drv.h because it isn't necessary if super_pages is compiled out in
> v3d_huge_mnt_init().
>
> In v3d_huge_mnt_init(), I'd add the #ifdef before the ret variable
> declaration and the #endif right after the last else so that it's clear
> drm_notice("THP is recommended...") is called unconditionally when
> CONFIG_TRANSPARENT_HUGEPAGE=n, whatever the optim level. What do you think?
First off, I'm not a huge fan of the following pattern
#if foo
if (xxxx)
#endif
do_something
which also applies to
#if foo
if (xxxx)
do_xxx
else if (yyy)
do_yyy
else
#endif
do_something
I'd rather have do_something duplicated in an #else section
like that:
#if foo
if (xxxx)
do_xxx
else if (yyy)
do_yyy
else
do_something
#else
do_something
#endif
But I'm not even seeing what the problem is here. If you do:
int err = 0;
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
if (super_pages)
err = drm_gem_huge_mnt_create(&v3d->drm, "within_size");
#endif
if (v3d->drm.huge_mnt)
drm_info(&v3d->drm, "Using Transparent Hugepages\n");
else if (err)
drm_warn(&v3d->drm, "Can't use Transparent Hugepages (%d)\n", err);
else
drm_notice(&v3d->drm,
"Transparent Hugepage support is recommended for optimal performance on this platform!\n");
You're guaranteed that err=0 and v3d->drm.huge_mnt=NULL when
CONFIG_TRANSPARENT_HUGEPAGE=n, so the "THP recommended"
message should be displayed unconditionally. Am I missing
something?
next prev parent reply other threads:[~2025-10-16 5:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-15 15:30 [PATCH v4 00/13] drm: Reduce page tables overhead with THP Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 01/13] drm/shmem-helper: Simplify page offset calculation in fault handler Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 02/13] drm/shmem-helper: Implement map_pages fault-around handler Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 03/13] drm/shmem-helper: Map huge pages in fault handlers Loïc Molinari
2025-10-15 17:27 ` Matthew Wilcox
2025-10-16 11:17 ` Loïc Molinari
2025-10-17 21:42 ` Matthew Wilcox
2025-11-10 14:39 ` Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 04/13] drm/gem: Introduce drm_gem_get_unmapped_area() fop Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 05/13] drm/gem: Add huge tmpfs mount point helper Loïc Molinari
2025-10-20 9:10 ` Tvrtko Ursulin
2025-10-20 14:13 ` Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 06/13] drm/i915: Use " Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 07/13] drm/v3d: " Loïc Molinari
2025-10-20 9:33 ` Tvrtko Ursulin
2025-10-20 14:27 ` Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 08/13] drm/v3d: Fix builds with CONFIG_TRANSPARENT_HUGEPAGE=n Loïc Molinari
2025-10-15 18:17 ` Boris Brezillon
2025-10-15 20:41 ` Loïc Molinari
2025-10-16 5:56 ` Boris Brezillon [this message]
2025-10-16 7:09 ` Loïc Molinari
2025-10-16 7:22 ` Boris Brezillon
2025-10-15 15:30 ` [PATCH v4 09/13] drm/gem: Get rid of *_with_mnt helpers Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 10/13] drm/panthor: Introduce huge tmpfs mount point option Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 11/13] drm/panthor: Improve IOMMU map/unmap debugging logs Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 12/13] drm/panfrost: Introduce huge tmpfs mount point option Loïc Molinari
2025-10-15 15:30 ` [PATCH v4 13/13] Documentation/gpu/drm-mm: Add THP paragraph to GEM mapping section Loïc Molinari
2025-10-15 19:01 ` ✗ i915.CI.BAT: failure for drm: Reduce page tables overhead with THP Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251016075637.3aec3465@fedora \
--to=boris.brezillon@collabora.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andi.shyti@linux.intel.com \
--cc=bagasdotme@gmail.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=healych@amazon.com \
--cc=hughd@google.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kernel@collabora.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liviu.dudau@arm.com \
--cc=loic.molinari@collabora.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mcanal@igalia.com \
--cc=mikolaj.wasiak@intel.com \
--cc=mripard@kernel.org \
--cc=mwen@igalia.com \
--cc=nitin.r.gote@intel.com \
--cc=robh@kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=tursulin@ursulin.net \
--cc=tzimmermann@suse.de \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.