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
next prev 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: linkBe 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.