All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Zeng, Oak" <oak.zeng@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"Thomas.Hellstrom@linux.intel.com"
	<Thomas.Hellstrom@linux.intel.com>
Subject: Re: [PATCH] drm/xe: Avoid evicting object of the same vm in none fault mode
Date: Fri, 6 Dec 2024 10:53:59 -0500	[thread overview]
Message-ID: <Z1MeFx6FcpA9qOz3@intel.com> (raw)
In-Reply-To: <MN2PR11MB4728D59473D4DFD67330171092312@MN2PR11MB4728.namprd11.prod.outlook.com>

On Fri, Dec 06, 2024 at 03:19:30PM +0000, Zeng, Oak wrote:
> Hi Rodrigo,
> 
> > -----Original Message-----
> > From: Vivi, Rodrigo <rodrigo.vivi@intel.com>
> > Sent: December 6, 2024 9:46 AM
> > To: Zeng, Oak <oak.zeng@intel.com>
> > Cc: intel-xe@lists.freedesktop.org;
> > Thomas.Hellstrom@linux.intel.com
> > Subject: Re: [PATCH] drm/xe: Avoid evicting object of the same vm in
> > none fault mode
> > 
> > On Mon, Dec 02, 2024 at 09:19:29PM -0500, Oak Zeng wrote:
> > > BO validation during vm_bind could trigger memory eviction when
> > > system runs under memory pressure. Right now we blindly evict
> > > BOs of all VMs. This scheme has a problem when system runs in
> > > none recoverable page fault mode: even though the vm_bind could
> > > be successful by evicting BOs, the later the rebinding of the
> > > evicted BOs would fail. So it is better to report an out-of-
> > > memory failure at vm_bind time than at time of rebinding where
> > > xekmd currently doesn't have a good mechanism to report error
> > > to user space.
> > >
> > > This patch implemented a scheme to only evict objects of other
> > > VMs during vm_bind time. Object of the same VM will skip eviction.
> > > If we failed to find enough memory for vm_bind, we report error
> > > to user space at vm_bind time.
> > >
> > > This scheme is not needed for recoverable page fault mode under
> > > what we can dynamically fault-in pages on demand.
> > >
> > > v1: Use xe_vm_in_preempt_fence_mode instead of stack variable
> > (Thomas)
> > >
> > > Signed-off-by: Oak Zeng <oak.zeng@intel.com>
> > > Suggested-by: Thomas Hellström
> > <thomas.hellstrom@linux.intel.com>
> > > Reviewed-by: Thomas Hellström
> > <thomas.hellstrom@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/xe/xe_vm.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/xe/xe_vm.c
> > b/drivers/gpu/drm/xe/xe_vm.c
> > > index 2492750505d69..016fedae5d554 100644
> > > --- a/drivers/gpu/drm/xe/xe_vm.c
> > > +++ b/drivers/gpu/drm/xe/xe_vm.c
> > > @@ -2359,13 +2359,15 @@ static int vma_lock_and_validate(struct
> > drm_exec *exec, struct xe_vma *vma,
> > >  				 bool validate)
> > >  {
> > >  	struct xe_bo *bo = xe_vma_bo(vma);
> > > +	struct xe_vm *vm = xe_vma_vm(vma);
> > 
> > for single usage like below we should avoid variable declaration,
> > specially in
> > this case where you do have line space left there... then it gets even
> > clear
> > that the only change in the patch is
> > 
> > - true
> > + !xe_vm_in_preempt_fence_mode(vm)
> 
> Are you suggesting to remove above line "+	struct xe_vm *vm = xe_vma_vm(vma);"?
> 
> Vm variable is used twice below, not single.
> 
> If I remove vm variable, then below I should write:
> 
> Xe_bo_validate(bo, xe_vma_vm(vma), !xe_vm_in_preempt_fence_mode(xe_vma_vm(vma)));

although I liked the 3 usages case like Matt Roper was consistently trying to
apply, when looking to this line like this, I do prefer your original version...

Please ignore me... I'm merging this patch as is right now...

Sorry and Thanks


> 
> Is this what you are suggesting?
> 
> Oak
> 
> > 
> > >  	int err = 0;
> > >
> > >  	if (bo) {
> > >  		if (!bo->vm)
> > >  			err = drm_exec_lock_obj(exec, &bo-
> > >ttm.base);
> > >  		if (!err && validate)
> > > -			err = xe_bo_validate(bo, xe_vma_vm(vma),
> > true);
> > > +			err = xe_bo_validate(bo, vm,
> > > +
> > 	     !xe_vm_in_preempt_fence_mode(vm));
> > >  	}
> > >
> > >  	return err;
> > > --
> > > 2.26.3
> > >

  reply	other threads:[~2024-12-06 15:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-03  2:19 [PATCH] drm/xe: Avoid evicting object of the same vm in none fault mode Oak Zeng
2024-12-03  2:10 ` ✓ CI.Patch_applied: success for drm/xe: Avoid evicting object of the same vm in none fault mode (rev2) Patchwork
2024-12-03  2:11 ` ✓ CI.checkpatch: " Patchwork
2024-12-03  2:12 ` ✓ CI.KUnit: " Patchwork
2024-12-03  2:30 ` ✓ CI.Build: " Patchwork
2024-12-03  2:32 ` ✓ CI.Hooks: " Patchwork
2024-12-03  2:34 ` ✓ CI.checksparse: " Patchwork
2024-12-03  2:54 ` ✓ Xe.CI.BAT: " Patchwork
2024-12-03  4:00 ` ✗ Xe.CI.Full: failure " Patchwork
2024-12-06 14:45 ` [PATCH] drm/xe: Avoid evicting object of the same vm in none fault mode Rodrigo Vivi
2024-12-06 15:19   ` Zeng, Oak
2024-12-06 15:53     ` Rodrigo Vivi [this message]
  -- strict thread matches above, loose matches on Subject: below --
2024-11-28 21:01 Oak Zeng
2024-11-29  8:45 ` Thomas Hellström
2024-11-28 20:58 Oak Zeng

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=Z1MeFx6FcpA9qOz3@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=Thomas.Hellstrom@linux.intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=oak.zeng@intel.com \
    /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.