[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 1/2] drm/msm: Enable THP for GEM buffers

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unchecked ERR_PTR and dangling pointers from drm_gem_huge_mnt_create cause catastrophic GEM allocation failures or Use-After-Free.
--

commit cb4549ef63304d3139dafdf100bc5423a484100d
Author: Rob Clark <robin.clark@oss.qualcomm.com>

drm/msm: Enable THP for GEM buffers

This patch enables Transparent Hugepage (THP) support for GEM buffers in the
MSM DRM driver by introducing a module parameter and initializing it during
device setup.

> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index db1b655dd055b..b96bad6e154a6 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;

[ ... ]

> +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))
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Severity: High]
This is a pre-existing issue, but does this correctly handle error returns
from drm_gem_huge_mnt_create()?

If drm_gem_huge_mnt_create() fails, it can leave an ERR_PTR or a dangling
pointer in dev->huge_mnt. Because this code evaluates the truthiness of
drm_gem_get_huge_mnt(dev) before checking the err variable, it will
evaluate to true for these error pointers and falsely indicate success.

Later, when drm_gem_object_init() passes this invalid pointer to
shmem_file_setup_with_mnt(), it can lead to a use-after-free or continuous
allocation failures. Should this code check for IS_ERR() or check the err
variable first before assuming the mount was successful?

> +		drm_info(dev, "Using Transparent Hugepage\n");
> +	else if (err)
> +		drm_warn(dev, "Can't use Transparent Hugepage (%d)\n", err);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260912145922.24115-1-robin.clark@oss.qualcomm.com?part=1

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] msm_gem_shrinker_scan incorrectly returns SHRINK_STOP when pages are successfully freed but the scanned LRU becomes empty, or when the scan yields no freed pages but pages remain.
--

commit 9512c359aecfd18777a053ee1d115de39b75b08a
Author: Rob Clark <robin.clark@oss.qualcomm.com>

drm/msm/gem: Add modparam to disable shrinker blocking

This commit adds a module parameter, eviction_can_block, to disable the
shrinker's ability to block waiting for GEM buffers to become idle. This
provides a way to avoid latency issues during memory pressure for sensitive
use-cases.

> diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c b/drivers/gpu/drm/msm/msm_gem_shrinker.c
> index 3514d5c849896..83ee032cb21d7 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));
>  }

[Severity: High]
This is a pre-existing issue, but does msm_gem_shrinker_scan() correctly
report reclaimed memory?

In drivers/gpu/drm/msm/msm_gem_shrinker.c:msm_gem_shrinker_scan(), the
return value uses a ternary operation:

	return (freed > 0 && remaining > 0) ? freed : SHRINK_STOP;

If the scan successfully frees all remaining pages in the LRU (remaining
becomes 0, freed > 0), wouldn't this evaluate to SHRINK_STOP? When
do_shrink_slab() receives SHRINK_STOP, it breaks its scanning loop and
bypasses accounting for the successfully freed pages, causing them to be
lost from shrinker accounting.

Similarly, if the scan fails to free any pages because the objects are
active or locked (freed is 0, remaining > 0), it also evaluates to
SHRINK_STOP. Wouldn't this cause do_shrink_slab() to abort scanning the
msm_gem slab entirely for this cycle?

This means unfreeable objects at the head of the LRU completely block the
reclaim of reclaimable objects further down the list, which could severely
impact the system's ability to reclaim GPU memory under pressure.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260912145922.24115-1-robin.clark@oss.qualcomm.com?part=2