All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo@kvack.org, "Michal Hocko <mhocko@suse.com>,
	kvm@vger.kernel.org,  \" Radim Krčmář <rkrcmar@redhat.com>,
	David Airlie" <airlied@linux.ie>,
	"Sudeep Dutt" <sudeep.dutt@intel.com>,
	dri-devel@lists.freedesktop.org, Deucher@kvack.org,
	linux-mm@kvack.org, Mike@kvack.org, Vivi@kvack.org,
	Juergen@kvack.org, "Andrea Arcangeli" <aarcange@redhat.com>,
	"Dimitri Sivanich" <sivanich@sgi.com>,
	Paolo@kvack.org, Dennis@kvack.org, linux-rdma@vger.kernel.org,
	amd-gfx@lists.freedesktop.org, Boris@kvack.org,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Doug Ledford" <dledford@redhat.com>,
	"David Rientjes" <rientjes@google.com>,
	xen-devel@lists.xenproject.org, Ashutosh@kvack.org,
	Marciniszyn@kvack.org, Alex@kvack.org,
	intel-gfx@lists.freedesktop.org, Dalessandro@kvack.org,
	"\" Jérôme Glisse" <jglisse@redhat.com>,
	Ostrovsky@k
Subject: Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
Date: Fri, 22 Jun 2018 17:57:16 +0200	[thread overview]
Message-ID: <20180622155716.GE10465@dhcp22.suse.cz> (raw)
In-Reply-To: <152968180950.11773.3374981930722769733@mail.alporthouse.com>

On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> Quoting Michal Hocko (2018-06-22 16:02:42)
> > Hi,
> > this is an RFC and not tested at all. I am not very familiar with the
> > mmu notifiers semantics very much so this is a crude attempt to achieve
> > what I need basically. It might be completely wrong but I would like
> > to discuss what would be a better way if that is the case.
> > 
> > get_maintainers gave me quite large list of people to CC so I had to trim
> > it down. If you think I have forgot somebody, please let me know
> 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > index 854bd51b9478..5285df9331fa 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object *mo)
> >         mo->attached = false;
> >  }
> >  
> > -static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > +static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> >                                                        struct mm_struct *mm,
> >                                                        unsigned long start,
> > -                                                      unsigned long end)
> > +                                                      unsigned long end,
> > +                                                      bool blockable)
> >  {
> >         struct i915_mmu_notifier *mn =
> >                 container_of(_mn, struct i915_mmu_notifier, mn);
> > @@ -124,7 +125,7 @@ static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> >         LIST_HEAD(cancelled);
> >  
> >         if (RB_EMPTY_ROOT(&mn->objects.rb_root))
> > -               return;
> > +               return 0;
> 
> The principle wait here is for the HW (even after fixing all the locks
> to be not so coarse, we still have to wait for the HW to finish its
> access).

Is this wait bound or it can take basically arbitrary amount of time?

> The first pass would be then to not do anything here if
> !blockable.

something like this? (incremental diff)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 5285df9331fa..e9ed0d2cfabc 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -122,6 +122,7 @@ static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
 		container_of(_mn, struct i915_mmu_notifier, mn);
 	struct i915_mmu_object *mo;
 	struct interval_tree_node *it;
+	int ret = 0;
 	LIST_HEAD(cancelled);
 
 	if (RB_EMPTY_ROOT(&mn->objects.rb_root))
@@ -133,6 +134,10 @@ static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
 	spin_lock(&mn->lock);
 	it = interval_tree_iter_first(&mn->objects, start, end);
 	while (it) {
+		if (!blockable) {
+			ret = -EAGAIN;
+			goto out_unlock;
+		}
 		/* The mmu_object is released late when destroying the
 		 * GEM object so it is entirely possible to gain a
 		 * reference on an object in the process of being freed
@@ -154,8 +159,10 @@ static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
 	spin_unlock(&mn->lock);
 
 	/* TODO: can we skip waiting here? */
-	if (!list_empty(&cancelled) && blockable)
+	if (!list_empty(&cancelled))
 		flush_workqueue(mn->wq);
+
+	return ret;
 }
 
 static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
-- 
Michal Hocko
SUSE Labs
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"Michal Hocko <mhocko@suse.com>,
	kvm@vger.kernel.org,  \" Radim Krčmář <rkrcmar@redhat.com>,
	David Airlie" <airlied@linux.ie>,
	"Sudeep Dutt" <sudeep.dutt@intel.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"David (ChunMing) Zhou" <David1.Zhou@amd.com>,
	"Dimitri Sivanich" <sivanich@sgi.com>,
	linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Doug Ledford" <dledford@redhat.com>,
	"David Rientjes" <rientjes@google.com>,
	xen-devel@lists.xenproject.org, intel-gfx@lists.freedesktop.org,
	"\" Jérôme Glisse" <jglisse@redhat.com>,
	Rodrigo@kvack.org, Vivi@kvack.org, Boris@kvack.org,
	Ostrovsky@kvack.org, Juergen@kvack.org, Gross@kvack.org,
	Mike@kvack.org, Marciniszyn@kvack.org, Dennis@kvack.org,
	Dalessandro@kvack.org, Ashutosh@kvack.org, Dixit@kvack.org,
	Alex@kvack.org, Deucher@kvack.org, Paolo@kvack.org,
	Bonzini@kvack.org
Subject: Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
Date: Fri, 22 Jun 2018 17:57:16 +0200	[thread overview]
Message-ID: <20180622155716.GE10465@dhcp22.suse.cz> (raw)
In-Reply-To: <152968180950.11773.3374981930722769733@mail.alporthouse.com>

On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> Quoting Michal Hocko (2018-06-22 16:02:42)
> > Hi,
> > this is an RFC and not tested at all. I am not very familiar with the
> > mmu notifiers semantics very much so this is a crude attempt to achieve
> > what I need basically. It might be completely wrong but I would like
> > to discuss what would be a better way if that is the case.
> > 
> > get_maintainers gave me quite large list of people to CC so I had to trim
> > it down. If you think I have forgot somebody, please let me know
> 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > index 854bd51b9478..5285df9331fa 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object *mo)
> >         mo->attached = false;
> >  }
> >  
> > -static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > +static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> >                                                        struct mm_struct *mm,
> >                                                        unsigned long start,
> > -                                                      unsigned long end)
> > +                                                      unsigned long end,
> > +                                                      bool blockable)
> >  {
> >         struct i915_mmu_notifier *mn =
> >                 container_of(_mn, struct i915_mmu_notifier, mn);
> > @@ -124,7 +125,7 @@ static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> >         LIST_HEAD(cancelled);
> >  
> >         if (RB_EMPTY_ROOT(&mn->objects.rb_root))
> > -               return;
> > +               return 0;
> 
> The principle wait here is for the HW (even after fixing all the locks
> to be not so coarse, we still have to wait for the HW to finish its
> access).

Is this wait bound or it can take basically arbitrary amount of time?

> The first pass would be then to not do anything here if
> !blockable.

something like this? (incremental diff)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 5285df9331fa..e9ed0d2cfabc 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -122,6 +122,7 @@ static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
 		container_of(_mn, struct i915_mmu_notifier, mn);
 	struct i915_mmu_object *mo;
 	struct interval_tree_node *it;
+	int ret = 0;
 	LIST_HEAD(cancelled);
 
 	if (RB_EMPTY_ROOT(&mn->objects.rb_root))
@@ -133,6 +134,10 @@ static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
 	spin_lock(&mn->lock);
 	it = interval_tree_iter_first(&mn->objects, start, end);
 	while (it) {
+		if (!blockable) {
+			ret = -EAGAIN;
+			goto out_unlock;
+		}
 		/* The mmu_object is released late when destroying the
 		 * GEM object so it is entirely possible to gain a
 		 * reference on an object in the process of being freed
@@ -154,8 +159,10 @@ static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
 	spin_unlock(&mn->lock);
 
 	/* TODO: can we skip waiting here? */
-	if (!list_empty(&cancelled) && blockable)
+	if (!list_empty(&cancelled))
 		flush_workqueue(mn->wq);
+
+	return ret;
 }
 
 static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
-- 
Michal Hocko
SUSE Labs

  parent reply	other threads:[~2018-06-22 15:57 UTC|newest]

Thread overview: 124+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-22 15:02 [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers Michal Hocko
2018-06-22 15:02 ` Michal Hocko
2018-06-22 15:02 ` Michal Hocko
2018-06-22 15:06 ` ✗ Fi.CI.BAT: failure for " Patchwork
2018-06-22 15:13 ` [RFC PATCH] " Christian König
2018-06-22 15:13   ` Christian König
2018-06-22 15:13   ` Christian König
2018-06-22 15:24   ` Michal Hocko
2018-06-22 15:24   ` Michal Hocko
2018-06-22 15:24     ` Michal Hocko
2018-06-22 15:24     ` Michal Hocko
2018-06-22 20:09     ` Felix Kuehling
     [not found]     ` <20180622152444.GC10465-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-06-22 20:09       ` Felix Kuehling
2018-06-22 20:09         ` Felix Kuehling
2018-06-22 20:09         ` Felix Kuehling
2018-06-25  8:01         ` Michal Hocko
2018-06-25  8:01         ` Michal Hocko
2018-06-25  8:01           ` Michal Hocko
2018-06-25  8:01           ` Michal Hocko
2018-06-25 13:31           ` Michal Hocko
     [not found]           ` <20180625080103.GB28965-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-06-25 13:31             ` Michal Hocko
2018-06-25 13:31               ` Michal Hocko
2018-06-25 13:31               ` Michal Hocko
2018-06-22 15:13 ` Christian König
2018-06-22 15:36 ` [Intel-gfx] " Chris Wilson
2018-06-22 16:01 ` ✗ Fi.CI.BAT: failure for mm, oom: distinguish blockable mode for mmu notifiers (rev2) Patchwork
2018-06-24  8:11 ` [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers Paolo Bonzini
2018-06-25  7:57   ` Michal Hocko
2018-06-25  8:10     ` Paolo Bonzini
2018-06-25  8:45       ` Michal Hocko
2018-06-25 10:34         ` Paolo Bonzini
2018-06-25 11:08           ` Michal Hocko
2018-06-25 10:23 ` ✗ Fi.CI.CHECKPATCH: warning for mm, oom: distinguish blockable mode for mmu notifiers (rev3) Patchwork
2018-06-25 10:56 ` ✓ Fi.CI.BAT: success " Patchwork
2018-06-25 13:50 ` ✗ Fi.CI.CHECKPATCH: warning for mm, oom: distinguish blockable mode for mmu notifiers (rev4) Patchwork
2018-06-25 14:00 ` ✓ Fi.CI.IGT: success for mm, oom: distinguish blockable mode for mmu notifiers (rev3) Patchwork
2018-06-25 14:10 ` ✓ Fi.CI.BAT: success for mm, oom: distinguish blockable mode for mmu notifiers (rev4) Patchwork
2018-06-25 19:22 ` ✓ Fi.CI.IGT: " Patchwork
     [not found] ` <20180622150242.16558-1-mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2018-06-22 15:36   ` [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers Chris Wilson
2018-06-22 15:36     ` Chris Wilson
2018-06-22 15:57     ` Michal Hocko
2018-06-22 15:57     ` Michal Hocko [this message]
2018-06-22 15:57       ` Michal Hocko
2018-06-22 16:18       ` Jerome Glisse
2018-06-22 16:18       ` Jerome Glisse
2018-06-22 16:18         ` Jerome Glisse
2018-06-22 16:18         ` Jerome Glisse
     [not found]         ` <20180622164026.GA23674@dhcp22.suse.cz>
2018-06-22 16:42           ` Michal Hocko
2018-06-22 16:42             ` [Intel-gfx] " Michal Hocko
2018-06-22 16:42             ` Michal Hocko
2018-06-22 17:26             ` [Intel-gfx] " Jerome Glisse
2018-06-22 17:26             ` Jerome Glisse
2018-06-22 17:26               ` [Intel-gfx] " Jerome Glisse
2018-06-22 16:42           ` Michal Hocko
     [not found]       ` <152968364170.11773.4392861266443293819@mail.alporthouse.com>
2018-06-22 16:19         ` Michal Hocko
2018-06-22 16:19           ` Michal Hocko
2018-06-22 16:19         ` Michal Hocko
2018-06-22 16:25     ` Jerome Glisse
2018-06-27  7:44   ` Michal Hocko
2018-06-27  7:44     ` Michal Hocko
2018-06-27  7:44     ` Michal Hocko
     [not found]     ` <20180627074421.GF32348-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-07-02  9:14       ` Christian König
2018-07-02  9:14         ` Christian König
2018-07-02  9:14         ` Christian König
2018-07-02 11:54         ` Michal Hocko
2018-07-02 11:54         ` Michal Hocko
2018-07-02 11:54           ` Michal Hocko
2018-07-02 11:54           ` Michal Hocko
2018-07-02 12:13           ` Christian König
2018-07-02 12:13           ` Christian König
2018-07-02 12:13             ` Christian König
2018-07-02 12:13             ` Christian König
2018-07-02 12:20             ` Michal Hocko
2018-07-02 12:20             ` Michal Hocko
2018-07-02 12:20               ` Michal Hocko
2018-07-02 12:20               ` Michal Hocko
2018-07-02 12:24               ` Christian König
2018-07-02 12:24                 ` Christian König
2018-07-02 12:24                 ` Christian König
2018-07-02 12:35                 ` Michal Hocko
     [not found]                 ` <02d1d52c-f534-f899-a18c-a3169123ac7c-5C7GfCeVMHo@public.gmane.org>
2018-07-02 12:35                   ` Michal Hocko
2018-07-02 12:35                     ` Michal Hocko
2018-07-02 12:35                     ` Michal Hocko
2018-07-02 12:39                     ` Christian König
     [not found]                     ` <20180702123521.GO19043-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-07-02 12:39                       ` Christian König
2018-07-02 12:39                         ` Christian König
2018-07-02 12:39                         ` Christian König
     [not found]                         ` <91ad1106-6bd4-7d2c-4d40-7c5be945ba36-5C7GfCeVMHo@public.gmane.org>
2018-07-02 12:56                           ` Michal Hocko
2018-07-02 12:56                             ` Michal Hocko
2018-07-02 12:56                             ` Michal Hocko
2018-07-02 12:56                         ` Michal Hocko
2018-07-02 12:24               ` Christian König
2018-07-09 12:29       ` Michal Hocko
2018-07-09 12:29         ` Michal Hocko
2018-07-09 12:29         ` Michal Hocko
     [not found]         ` <20180709122908.GJ22049-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-07-10 13:40           ` Leon Romanovsky
2018-07-10 13:40             ` Leon Romanovsky
2018-07-10 14:14             ` Michal Hocko
2018-07-10 14:14               ` Michal Hocko
2018-07-10 16:20               ` Leon Romanovsky
2018-07-10 16:20                 ` Leon Romanovsky
     [not found]                 ` <20180710162020.GJ3014-U/DQcQFIOTAkZy+6dPanYNBPR1lH4CV8@public.gmane.org>
2018-07-11  9:03                   ` Michal Hocko
2018-07-11  9:03                     ` Michal Hocko
2018-07-11 10:14                     ` Leon Romanovsky
2018-07-11 10:14                       ` Leon Romanovsky
2018-07-11 11:13                       ` Michal Hocko
2018-07-11 11:13                       ` Michal Hocko
2018-07-11 11:13                         ` Michal Hocko
2018-07-11 12:08                         ` Leon Romanovsky
     [not found]                         ` <20180711111318.GL20050-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-07-11 12:08                           ` Leon Romanovsky
2018-07-11 12:08                             ` Leon Romanovsky
2018-07-11 10:14                     ` Leon Romanovsky
2018-07-11  9:03                 ` Michal Hocko
2018-07-10 16:20               ` Leon Romanovsky
     [not found]               ` <20180710141410.GP14284-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-07-16  7:59                 ` Leon Romanovsky
2018-07-16  7:59                   ` Leon Romanovsky
2018-07-16  7:59               ` Leon Romanovsky
2018-07-10 14:14             ` Michal Hocko
2018-07-10 13:40         ` Leon Romanovsky
2018-07-02  9:14     ` Christian König
2018-07-09 12:29     ` Michal Hocko
2018-06-27  7:44 ` Michal Hocko
2018-06-27  9:05 ` ✗ Fi.CI.BAT: failure for mm, oom: distinguish blockable mode for mmu notifiers (rev5) Patchwork
2018-07-11 10:57 ` ✗ Fi.CI.BAT: failure for mm, oom: distinguish blockable mode for mmu notifiers (rev6) Patchwork

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=20180622155716.GE10465@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=Alex@kvack.org \
    --cc=Ashutosh@kvack.org \
    --cc=Boris@kvack.org \
    --cc=Dalessandro@kvack.org \
    --cc=Dennis@kvack.org \
    --cc=Deucher@kvack.org \
    --cc=Juergen@kvack.org \
    --cc=Marciniszyn@kvack.org \
    --cc=Mike@kvack.org \
    --cc=Ostrovsky@k \
    --cc=Paolo@kvack.org \
    --cc=Rodrigo@kvack.org \
    --cc=Vivi@kvack.org \
    --cc=aarcange@redhat.com \
    --cc=airlied@linux.ie \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=dledford@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=sivanich@sgi.com \
    --cc=sudeep.dutt@intel.com \
    --cc=xen-devel@lists.xenproject.org \
    /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.