From: Daniel Vetter <daniel@ffwll.ch> To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: jglisse@redhat.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, David Airlie <airlied@linux.ie>, Daniel Vetter <daniel.vetter@ffwll.ch>, Chris Wilson <chris@chris-wilson.co.uk>, Lionel Landwerlin <lionel.g.landwerlin@intel.com>, Jani Nikula <jani.nikula@linux.intel.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>, intel-gfx@lists.freedesktop.org Subject: Re: [PATCH 2/2] gpu/i915: use HMM mirror for userptr buffer object. Date: Thu, 22 Nov 2018 15:31:04 +0100 [thread overview] Message-ID: <20181122143104.GF4266@phenom.ffwll.local> (raw) In-Reply-To: <154289518994.19402.3481838548028068213@jlahtine-desk.ger.corp.intel.com> On Thu, Nov 22, 2018 at 03:59:50PM +0200, Joonas Lahtinen wrote: > Hi Jerome, > > Bit late reply, but here goes :) > > We're working quite hard to avoid pinning any pages unless they're in > the GPU page tables. And when they are in the GPU page tables, they must > be pinned for whole of that duration, for the reason that our GPUs can > not take a fault. And to avoid thrashing GPU page tables, we do leave > objects in page tables with the expectation that smart userspace > recycles buffers. > > So what I understand of your proposal, it wouldn't really make a > difference for us in the amount of pinned pages (which I agree, > we'd love to see going down). When we're unable to take a fault, > the first use effectively forces us to pin any pages and keep them > pinned to avoid thrashing GPU page tables. > > So from i915 perspective, it just seems to be mostly an exchange of > an API to an another for getting the pages. You already mentioned > the fast path is being worked on, which is an obvious difference. > But is there some other improvement one would be expecting, beyond > the page pinning? > > Also, is the requirement for a single non-file-backed VMA in the > plans of being eliminated or is that inherent restriction of the > HMM_MIRROR feature? We're currently not imposing such a limitation. I think a clear plus for HMM would be if this helps us fix the deadlocks and races we're seeing. But I have no idea whether this gets us any closer here or not. -Daniel > > Regards, Joonas > > Quoting jglisse@redhat.com (2018-09-10 03:57:36) > > From: Jérôme Glisse <jglisse@redhat.com> > > > > This replace existing code that rely on get_user_page() aka GUP with > > code that now use HMM mirror to mirror a range of virtual address as > > a buffer object accessible by the GPU. There is no functional changes > > from userspace point of view. > > > > From kernel point of view we no longer pin pages for userptr buffer > > object which is a welcome change (i am assuming that everyone dislike > > page pin as i do). > > > > Another change, from kernel point of view, is that it does no longer > > have a fast path with get_user_pages_fast() this can eventually added > > back through HMM. > > > > Signed-off-by: Jérôme Glisse <jglisse@redhat.com> > > Cc: dri-devel@lists.freedesktop.org > > Cc: David Airlie <airlied@linux.ie> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > > Cc: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> > > Cc: Jani Nikula <jani.nikula@linux.intel.com> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Cc: intel-gfx@lists.freedesktop.org -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch> To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: David Airlie <airlied@linux.ie>, Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, jglisse@redhat.com, Rodrigo Vivi <rodrigo.vivi@intel.com> Subject: Re: [PATCH 2/2] gpu/i915: use HMM mirror for userptr buffer object. Date: Thu, 22 Nov 2018 15:31:04 +0100 [thread overview] Message-ID: <20181122143104.GF4266@phenom.ffwll.local> (raw) In-Reply-To: <154289518994.19402.3481838548028068213@jlahtine-desk.ger.corp.intel.com> On Thu, Nov 22, 2018 at 03:59:50PM +0200, Joonas Lahtinen wrote: > Hi Jerome, > > Bit late reply, but here goes :) > > We're working quite hard to avoid pinning any pages unless they're in > the GPU page tables. And when they are in the GPU page tables, they must > be pinned for whole of that duration, for the reason that our GPUs can > not take a fault. And to avoid thrashing GPU page tables, we do leave > objects in page tables with the expectation that smart userspace > recycles buffers. > > So what I understand of your proposal, it wouldn't really make a > difference for us in the amount of pinned pages (which I agree, > we'd love to see going down). When we're unable to take a fault, > the first use effectively forces us to pin any pages and keep them > pinned to avoid thrashing GPU page tables. > > So from i915 perspective, it just seems to be mostly an exchange of > an API to an another for getting the pages. You already mentioned > the fast path is being worked on, which is an obvious difference. > But is there some other improvement one would be expecting, beyond > the page pinning? > > Also, is the requirement for a single non-file-backed VMA in the > plans of being eliminated or is that inherent restriction of the > HMM_MIRROR feature? We're currently not imposing such a limitation. I think a clear plus for HMM would be if this helps us fix the deadlocks and races we're seeing. But I have no idea whether this gets us any closer here or not. -Daniel > > Regards, Joonas > > Quoting jglisse@redhat.com (2018-09-10 03:57:36) > > From: Jérôme Glisse <jglisse@redhat.com> > > > > This replace existing code that rely on get_user_page() aka GUP with > > code that now use HMM mirror to mirror a range of virtual address as > > a buffer object accessible by the GPU. There is no functional changes > > from userspace point of view. > > > > From kernel point of view we no longer pin pages for userptr buffer > > object which is a welcome change (i am assuming that everyone dislike > > page pin as i do). > > > > Another change, from kernel point of view, is that it does no longer > > have a fast path with get_user_pages_fast() this can eventually added > > back through HMM. > > > > Signed-off-by: Jérôme Glisse <jglisse@redhat.com> > > Cc: dri-devel@lists.freedesktop.org > > Cc: David Airlie <airlied@linux.ie> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > > Cc: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> > > Cc: Jani Nikula <jani.nikula@linux.intel.com> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Cc: intel-gfx@lists.freedesktop.org -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-11-22 14:31 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-10 0:57 [PATCH 0/2] [i915] Getting rid of GUP and use HMM for user ptr features jglisse 2018-09-10 0:57 ` jglisse 2018-09-10 0:57 ` [PATCH 1/2] gpu/i915: use HMM mirror instead of mmu_notifier jglisse 2018-09-10 0:57 ` jglisse 2018-09-10 0:57 ` [PATCH 2/2] gpu/i915: use HMM mirror for userptr buffer object jglisse 2018-09-10 0:57 ` jglisse 2018-11-22 13:59 ` Joonas Lahtinen 2018-11-22 13:59 ` Joonas Lahtinen 2018-11-22 14:31 ` Daniel Vetter [this message] 2018-11-22 14:31 ` Daniel Vetter 2018-09-10 9:27 ` ✗ Fi.CI.BAT: failure for Getting rid of GUP and use HMM for user ptr features 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=20181122143104.GF4266@phenom.ffwll.local \ --to=daniel@ffwll.ch \ --cc=airlied@linux.ie \ --cc=chris@chris-wilson.co.uk \ --cc=daniel.vetter@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=jani.nikula@linux.intel.com \ --cc=jglisse@redhat.com \ --cc=joonas.lahtinen@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lionel.g.landwerlin@intel.com \ --cc=rodrigo.vivi@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: 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.