All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: "Adrián Larumbe" <adrian.larumbe@collabora.com>
Cc: "Steven Price" <steven.price@arm.com>,
	"Liviu Dudau" <liviu.dudau@arm.com>,
	dri-devel@lists.freedesktop.org,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Akash Goel" <akash.goel@arm.com>,
	"Rob Clark" <robin.clark@oss.qualcomm.com>,
	"Sean Paul" <sean@poorly.run>,
	"Konrad Dybcio" <konradybcio@kernel.org>,
	"Akhil P Oommen" <akhilpo@oss.qualcomm.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
	"Chris Diamand" <chris.diamand@arm.com>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Chia-I Wu" <olvaffe@gmail.com>,
	kernel@collabora.com
Subject: Re: [PATCH v5 9/9] drm/panthor: Add a GEM shrinker
Date: Wed, 25 Mar 2026 09:13:19 +0100	[thread overview]
Message-ID: <20260325091319.4a08dada@fedora> (raw)
In-Reply-To: <acMahMlSFs1ym-rU@sobremesa>

On Tue, 24 Mar 2026 23:52:32 +0000
Adrián Larumbe <adrian.larumbe@collabora.com> wrote:

> > @@ -2178,8 +2222,10 @@ static int panthor_gpuva_sm_step_remap(struct drm_gpuva_op *op,
> >  	 * atomicity. panthor_vm_lock_region() bails out early if the new region
> >  	 * is already part of the locked region, so no need to do this check here.
> >  	 */
> > -	panthor_vm_lock_region(vm, unmap_start, unmap_range);
> > -	panthor_vm_unmap_pages(vm, unmap_start, unmap_range);
> > +	if (!unmap_vma->evicted) {
> > +		panthor_vm_lock_region(vm, unmap_start, unmap_range);
> > +		panthor_vm_unmap_pages(vm, unmap_start, unmap_range);
> > +	}
> >
> >  	if (op->remap.prev) {  
> 
> I think we'd want to make sure we don't map the pages for 'prev' when the original unmap
> vma is evicted, but we still want to create a new vma for it.

Absolutely. I'll fix that in v6.

> 
> >  		struct panthor_gem_object *bo = to_panthor_bo(op->remap.prev->gem.obj);
> > @@ -2193,6 +2239,7 @@ static int panthor_gpuva_sm_step_remap(struct drm_gpuva_op *op,
> >
> >  		prev_vma = panthor_vm_op_ctx_get_vma(op_ctx);
> >  		panthor_vma_init(prev_vma, unmap_vma->flags);
> > +		prev_vma->evicted = unmap_vma->evicted;
> >  	}
> >
> >  	if (op->remap.next) {  
> 
> Same as above.

Yep, will be fixed in v6.

> > +void panthor_vm_update_bo_reclaim_lru_locked(struct panthor_gem_object *bo)
> > +{
> > +	struct panthor_device *ptdev = container_of(bo->base.dev, struct panthor_device, base);
> > +	struct panthor_vm *vm = NULL;
> > +	struct drm_gpuvm_bo *vm_bo;
> > +
> > +	dma_resv_assert_held(bo->base.resv);
> > +	lockdep_assert_held(&bo->base.gpuva.lock);
> > +
> > +	drm_gem_for_each_gpuvm_bo(vm_bo, &bo->base) {
> > +		if (vm_bo->evicted)
> > +			continue;  
> 
> I found this a bit confusing, because this function is called for objects whose state is
> PANTHOR_GEM_GPU_MAPPED_PRIVATE, described as 'GEM is GPU mapped to only one VM'. So that
> made me think it was synonymous to panthor_gem_object::exclusive_vm_root_gem being set, but
> according to this code, a BO is shrinker-private if only one of its VM_BO's isn't evicted
> at any given time. I guess this definition is what matters wrt the shrinker, because it can
> go straight pick it up from the VM's reclaim.lru list. Maybe it'd be less confusing if
> the uAPI header file's description of PANTHOR_GEM_GPU_MAPPED_PRIVATE reflected this too?

I'll rename PANTHOR_GEM_GPU_MAPPED_PRIVATE into
PANTHOR_GEM_GPU_MAPPED_SINGLE_VM and PANTHOR_GEM_GPU_MAPPED_SHARED into
PANTHOR_GEM_GPU_MAPPED_MULTI_VM to clear the confusion.

> 
> > +		/* We're only supposed to have one non-evicted vm_bo in the list if we get
> > +		 * there.
> > +		 */
> > +		drm_WARN_ON(&ptdev->base, vm);
> > +		vm = container_of(vm_bo->vm, struct panthor_vm, base);
> > +
> > +		mutex_lock(&ptdev->reclaim.lock);
> > +		drm_gem_lru_move_tail_locked(&vm->reclaim.lru, &bo->base);
> > +		if (list_empty(&vm->reclaim.lru_node))
> > +			list_move(&vm->reclaim.lru_node, &ptdev->reclaim.vms);
> > +		mutex_unlock(&ptdev->reclaim.lock);
> > +	}
> > +}

  reply	other threads:[~2026-03-25  8:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09 15:11 [PATCH v5 0/9] drm/panthor: Add a GEM shrinker Boris Brezillon
2026-03-09 15:11 ` [PATCH v5 1/9] drm/gem: Consider GEM object reclaimable if shrinking fails Boris Brezillon
2026-03-09 15:11 ` [PATCH v5 2/9] drm/panthor: Move panthor_gems_debugfs_init() to panthor_gem.c Boris Brezillon
2026-03-09 15:11 ` [PATCH v5 3/9] drm/panthor: Group panthor_kernel_bo_xxx() helpers Boris Brezillon
2026-03-09 15:11 ` [PATCH v5 4/9] drm/panthor: Don't call drm_gpuvm_bo_extobj_add() if the object is private Boris Brezillon
2026-03-09 15:11 ` [PATCH v5 5/9] drm/panthor: Part ways with drm_gem_shmem_object Boris Brezillon
2026-03-09 15:34   ` Steven Price
2026-03-12 13:59   ` Liviu Dudau
2026-03-25  0:24   ` Adrián Larumbe
2026-03-25  7:59     ` Boris Brezillon
2026-03-09 15:11 ` [PATCH v5 6/9] drm/panthor: Lazily allocate pages on mmap() Boris Brezillon
2026-03-09 15:11 ` [PATCH v5 7/9] drm/panthor: Split panthor_vm_prepare_map_op_ctx() to prepare for reclaim Boris Brezillon
2026-03-09 15:11 ` [PATCH v5 8/9] drm/panthor: Track the number of mmap on a BO Boris Brezillon
2026-03-09 15:11 ` [PATCH v5 9/9] drm/panthor: Add a GEM shrinker Boris Brezillon
2026-03-24 23:52   ` Adrián Larumbe
2026-03-25  8:13     ` Boris Brezillon [this message]
2026-03-25  0:14   ` Adrián Larumbe
2026-03-25  8:10     ` Boris Brezillon

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=20260325091319.4a08dada@fedora \
    --to=boris.brezillon@collabora.com \
    --cc=adrian.larumbe@collabora.com \
    --cc=airlied@gmail.com \
    --cc=akash.goel@arm.com \
    --cc=akhilpo@oss.qualcomm.com \
    --cc=aliceryhl@google.com \
    --cc=chris.diamand@arm.com \
    --cc=dakr@kernel.org \
    --cc=dmitry.osipenko@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel@collabora.com \
    --cc=konradybcio@kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthew.brost@intel.com \
    --cc=mripard@kernel.org \
    --cc=olvaffe@gmail.com \
    --cc=robin.clark@oss.qualcomm.com \
    --cc=sean@poorly.run \
    --cc=simona@ffwll.ch \
    --cc=steven.price@arm.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tzimmermann@suse.de \
    /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.