[PATCH v2 1/2] drm/msm: Enable THP for GEM buffers

[PATCH v2 1/2] drm/msm: Enable THP for GEM buffers

[Rob Clark]

More than 2x speedup on darktable benchmark which was bottlenecked on
page allocation/pinning.

Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
---
v2: Initialize THP earlier
 drivers/gpu/drm/msm/msm_drv.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 73d99bde26f1..581903ccd5e6 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -58,9 +58,31 @@ static bool separate_gpu_kms;
 MODULE_PARM_DESC(separate_gpu_drm, "Use separate DRM device for the GPU (0=single DRM device for both GPU and display (default), 1=two DRM devices)");
 module_param(separate_gpu_kms, bool, 0400);
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+static bool transparent_hugepage = true;
+module_param(transparent_hugepage, bool, 0400);
+MODULE_PARM_DESC(transparent_hugepage, "Use a dedicated tmpfs mount point with Transparent Hugepage enabled (true = default)");
+#else
+#define transparent_hugepage false
+#endif
+
 DECLARE_FAULT_ATTR(fail_gem_alloc);
 DECLARE_FAULT_ATTR(fail_gem_iova);
 
+static void msm_gem_thp_init(struct drm_device *dev)
+{
+	int err;
+
+	if (!transparent_hugepage)
+		return;
+
+	err = drm_gem_huge_mnt_create(dev, "within_size");
+	if (drm_gem_get_huge_mnt(dev))
+		drm_info(dev, "Using Transparent Hugepage\n");
+	else if (err)
+		drm_warn(dev, "Can't use Transparent Hugepage (%d)\n", err);
+}
+
 bool msm_gpu_no_components(void)
 {
 	return separate_gpu_kms;
@@ -161,6 +183,8 @@ static int msm_drm_init(struct device *dev, const struct drm_driver *drv,
 	if (ret)
 		goto err_msm_uninit;
 
+	msm_gem_thp_init(ddev);
+
 	if (priv->kms_init) {
 		ret = msm_drm_kms_init(dev, drv);
 		if (ret)
-- 
2.55.0

[PATCH v2 2/2] drm/msm/gem: Add modparam to disable shrinker blocking

[Rob Clark]

Normally if we are under enough memory pressure, the shrinker will
eventually start waiting for BOs to become idle.  In some very latency
sensitive use-cases this is undesirable.

Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
---
 drivers/gpu/drm/msm/msm_gem_shrinker.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c b/drivers/gpu/drm/msm/msm_gem_shrinker.c
index 3514d5c84989..83ee032cb21d 100644
--- a/drivers/gpu/drm/msm/msm_gem_shrinker.c
+++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c
@@ -19,6 +19,10 @@ static bool enable_eviction = true;
 MODULE_PARM_DESC(enable_eviction, "Enable swappable GEM buffers");
 module_param(enable_eviction, bool, 0600);
 
+static bool eviction_can_block = true;
+MODULE_PARM_DESC(eviction_can_block, "Enable blocking for GEM buffer to become idle for eviction");
+module_param(eviction_can_block, bool, 0600);
+
 static bool can_swap(void)
 {
 	return enable_eviction && get_nr_swap_pages() > 0;
@@ -26,6 +30,8 @@ static bool can_swap(void)
 
 static bool can_block(struct shrink_control *sc)
 {
+	if (!eviction_can_block)
+		return false;
 	return (sc->gfp_mask & __GFP_DIRECT_RECLAIM) ||
 	       (current_is_kswapd() && (sc->gfp_mask & __GFP_KSWAPD_RECLAIM));
 }
-- 
2.55.0

Re: [PATCH v2 2/2] drm/msm/gem: Add modparam to disable shrinker blocking

[Konrad Dybcio]

On 9/12/26 4:59 PM, Rob Clark wrote:
> Normally if we are under enough memory pressure, the shrinker will
> eventually start waiting for BOs to become idle.  In some very latency
> sensitive use-cases this is undesirable.
> 
> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
> ---
>  drivers/gpu/drm/msm/msm_gem_shrinker.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c b/drivers/gpu/drm/msm/msm_gem_shrinker.c
> index 3514d5c84989..83ee032cb21d 100644
> --- a/drivers/gpu/drm/msm/msm_gem_shrinker.c
> +++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c
> @@ -19,6 +19,10 @@ static bool enable_eviction = true;
>  MODULE_PARM_DESC(enable_eviction, "Enable swappable GEM buffers");
>  module_param(enable_eviction, bool, 0600);
>  
> +static bool eviction_can_block = true;
> +MODULE_PARM_DESC(eviction_can_block, "Enable blocking for GEM buffer to become idle for eviction");
> +module_param(eviction_can_block, bool, 0600);
> +
>  static bool can_swap(void)
>  {
>  	return enable_eviction && get_nr_swap_pages() > 0;
> @@ -26,6 +30,8 @@ static bool can_swap(void)
>  
>  static bool can_block(struct shrink_control *sc)
>  {
> +	if (!eviction_can_block)
> +		return false;
>  	return (sc->gfp_mask & __GFP_DIRECT_RECLAIM) ||
>  	       (current_is_kswapd() && (sc->gfp_mask & __GFP_KSWAPD_RECLAIM));
>  }

This is just a guess, but can we always keep both and jump out
of msm_gem_shrinker_scan() early if we can satistfy nr_to_scan
without locking?

Konrad

Re: [PATCH v2 2/2] drm/msm/gem: Add modparam to disable shrinker blocking

[Rob Clark]

On Mon, Sep 14, 2026 at 12:56 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 9/12/26 4:59 PM, Rob Clark wrote:
> > Normally if we are under enough memory pressure, the shrinker will
> > eventually start waiting for BOs to become idle.  In some very latency
> > sensitive use-cases this is undesirable.
> >
> > Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
> > ---
> >  drivers/gpu/drm/msm/msm_gem_shrinker.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c b/drivers/gpu/drm/msm/msm_gem_shrinker.c
> > index 3514d5c84989..83ee032cb21d 100644
> > --- a/drivers/gpu/drm/msm/msm_gem_shrinker.c
> > +++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c
> > @@ -19,6 +19,10 @@ static bool enable_eviction = true;
> >  MODULE_PARM_DESC(enable_eviction, "Enable swappable GEM buffers");
> >  module_param(enable_eviction, bool, 0600);
> >
> > +static bool eviction_can_block = true;
> > +MODULE_PARM_DESC(eviction_can_block, "Enable blocking for GEM buffer to become idle for eviction");
> > +module_param(eviction_can_block, bool, 0600);
> > +
> >  static bool can_swap(void)
> >  {
> >       return enable_eviction && get_nr_swap_pages() > 0;
> > @@ -26,6 +30,8 @@ static bool can_swap(void)
> >
> >  static bool can_block(struct shrink_control *sc)
> >  {
> > +     if (!eviction_can_block)
> > +             return false;
> >       return (sc->gfp_mask & __GFP_DIRECT_RECLAIM) ||
> >              (current_is_kswapd() && (sc->gfp_mask & __GFP_KSWAPD_RECLAIM));
> >  }
>
> This is just a guess, but can we always keep both and jump out
> of msm_gem_shrinker_scan() early if we can satistfy nr_to_scan
> without locking?

We do this already.  But a pure vulkan/VM_BIND userspace that happens
to have realtime compositor requirements (vr) has a hard time under
heavy memory pressure.  Without BO tracking the kernel ends up quickly
looking for anything to evict and not necessarily making good choices.
I have some half baked ideas.. tracking LRU vm might help, etc.

BR,
-R