On Mon, Sep 14, 2026 at 12:56 AM Konrad Dybcio <[email protected]> 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 <[email protected]> > > --- > > 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
