From: John Brooks <john@fastquake.com>
To: "Christian König" <deathsimple@vodafone.de>
Cc: "Michel Dänzer" <michel@daenzer.net>,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 6/9] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS
Date: Sun, 25 Jun 2017 01:57:19 +0000 [thread overview]
Message-ID: <20170625015719.GA1567@kitsune.fastquake.com> (raw)
In-Reply-To: <55ea5e84-0791-5a70-6278-ade83c343a3b@vodafone.de>
On Sat, Jun 24, 2017 at 08:00:05PM +0200, Christian König wrote:
> Am 23.06.2017 um 19:39 schrieb John Brooks:
> >When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by userspace,
> >it should only be treated as a hint to initially place a BO somewhere CPU
> >accessible, rather than having a permanent effect on BO placement.
>
> And that is a clear NAK from my side.
>
> CPU_ACCESS_REQUIRED is a permanent limitation to where the buffer should be
> placed.
>
> Ignoring that and changing the IOCTL interface like this is clearly not
> acceptable.
>
> Christian.
>
In that case, I will remove this patch. But I will keep in some form the
safeguard against BOs oscillating between VRAM and GTT, as patch 3 allows page
faults to move BOs to GTT (more frequently than before, anyway). If userspace
has *not* marked said BOs with CPU_ACCESS_REQUIRED, amdgpu_cs_bo_validate will
move them to invisible VRAM, where they may promptly generate another page
fault. Cue framerate death. The same problem was seen last month in patch 2 of
the "Tweaks for high pressure on CPU visible VRAM" series.
John
> >
> >Instead of the flag being set in stone at BO creation, set the flag when a
> >page fault occurs so that it goes somewhere CPU-visible, and clear it when
> >the BO is requested by the GPU.
> >
> >However, clearing the CPU_ACCESS_REQUIRED flag may move a BO to invisible
> >VRAM, which is likely to cause a page fault that moves it right back to
> >GTT. When this happens too much, it is highly detrimental to performance.
> >Only clear the flag on CS if:
> >
> >- The BO wasn't page faulted for a certain amount of time (currently 10
> > seconds, measured with jiffies), and
> >- its last page fault didn't occur too soon (currently 500ms) after its
> > last CS request, or vice versa.
> >
> >Setting the flag in amdgpu_fault_reserve_notify() also means that we can
> >remove the loop to restrict lpfn to the end of visible VRAM, because
> >amdgpu_ttm_placement_init() will do it for us.
> >
> >Signed-off-by: John Brooks <john@fastquake.com>
> >---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 +
> > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 46 ++++++++++++++++++++++--------
> > drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 +
> > 3 files changed, 36 insertions(+), 12 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >index 2fad8bd..73d6882 100644
> >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >@@ -320,6 +320,7 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
> > else
> > domain = bo->allowed_domains;
> >+ amdgpu_bo_clear_cpu_access_required(bo);
> > retry:
> > amdgpu_ttm_placement_from_domain(bo, domain);
> > initial_bytes_moved = atomic64_read(&adev->num_bytes_moved);
> >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >index 31d1f21..a7d48a7 100644
> >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> >@@ -967,8 +967,8 @@ int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
> > {
> > struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
> > struct amdgpu_bo *abo;
> >- unsigned long offset, size, lpfn;
> >- int i, r;
> >+ unsigned long offset, size;
> >+ int r;
> > if (!amdgpu_ttm_bo_is_amdgpu_bo(bo))
> > return 0;
> >@@ -991,18 +991,9 @@ int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
> > /* hurrah the memory is not visible ! */
> > atomic64_inc(&adev->num_vram_cpu_page_faults);
> >+ abo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
> > amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_VRAM |
> > AMDGPU_GEM_DOMAIN_GTT);
> >- lpfn = adev->mc.visible_vram_size >> PAGE_SHIFT;
> >- for (i = 0; i < abo->placement.num_placement; i++) {
> >- /* Try to move the BO into visible VRAM */
> >- if ((abo->placements[i].flags & TTM_PL_FLAG_VRAM) &&
> >- (!abo->placements[i].lpfn ||
> >- abo->placements[i].lpfn > lpfn))
> >- abo->placements[i].lpfn = lpfn;
> >- }
> >- abo->placement.busy_placement = abo->placement.placement;
> >- abo->placement.num_busy_placement = abo->placement.num_placement;
> > r = ttm_bo_validate(bo, &abo->placement, false, false);
> > if (unlikely(r != 0))
> > return r;
> >@@ -1057,3 +1048,34 @@ u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo)
> > return bo->tbo.offset;
> > }
> >+
> >+/**
> >+ * amdgpu_bo_clear_cpu_access_required
> >+ * @bo: BO to update
> >+ *
> >+ * Clears CPU_ACCESS_REQUIRED flag if the BO hasn't had a page fault in a while
> >+ * and it didn't have a page fault too soon after the last time it was moved to
> >+ * VRAM.
> >+ *
> >+ * Caller should have bo reserved.
> >+ *
> >+ */
> >+void amdgpu_bo_clear_cpu_access_required(struct amdgpu_bo *bo)
> >+{
> >+ const unsigned int page_fault_timeout_ms = 10000;
> >+ const unsigned int min_period_ms = 500;
> >+ unsigned int ms_since_pf, period_ms;
> >+
> >+ ms_since_pf = jiffies_to_msecs(jiffies - bo->last_page_fault_jiffies);
> >+ period_ms = jiffies_to_msecs(abs(bo->last_page_fault_jiffies -
> >+ bo->last_cs_move_jiffies));
> >+
> >+ /*
> >+ * Try to avoid a revolving door between GTT and VRAM. Clearing the
> >+ * flag may move this BO back to VRAM, so don't clear it if it's likely
> >+ * to page fault and go right back to GTT.
> >+ */
> >+ if ((!bo->last_page_fault_jiffies || !bo->last_cs_move_jiffies) ||
> >+ (ms_since_pf > page_fault_timeout_ms && period_ms > min_period_ms))
> >+ bo->flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
> >+}
> >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> >index 3824851..b0cb137 100644
> >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> >@@ -182,6 +182,7 @@ int amdgpu_bo_restore_from_shadow(struct amdgpu_device *adev,
> > struct reservation_object *resv,
> > struct dma_fence **fence,
> > bool direct);
> >+void amdgpu_bo_clear_cpu_access_required(struct amdgpu_bo *bo);
> > /*
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-06-25 1:57 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-23 17:39 [PATCH 0/9] Visible VRAM Management Improvements John Brooks
2017-06-23 17:39 ` [PATCH 3/9] drm/amdgpu: Don't force BOs into visible VRAM for page faults John Brooks
[not found] ` <1498239580-17360-4-git-send-email-john-xq/Ko7C6e2Bl57MIdRCFDg@public.gmane.org>
2017-06-26 9:38 ` Michel Dänzer
[not found] ` <f399c192-d90d-9f43-9b8a-820fa51a7715-otUistvHUpPR7s880joybQ@public.gmane.org>
2017-06-27 3:25 ` John Brooks
2017-06-23 17:39 ` [PATCH 5/9] drm/amdgpu: Track time of last page fault and last CS move in struct amdgpu_bo John Brooks
2017-06-23 17:39 ` [PATCH 9/9] drm/amdgpu: Reduce lock contention when evicting from visible VRAM John Brooks
[not found] ` <1498239580-17360-1-git-send-email-john-xq/Ko7C6e2Bl57MIdRCFDg@public.gmane.org>
2017-06-23 17:39 ` [PATCH 1/9] drm/amdgpu: Separate placements and busy placements John Brooks
2017-06-23 17:39 ` [PATCH 2/9] drm/amdgpu: Add vis_vramlimit module parameter John Brooks
2017-06-26 9:48 ` Michel Dänzer
2017-06-26 9:57 ` Christian König
2017-06-23 17:39 ` [PATCH 4/9] drm/amdgpu: Don't force BOs into visible VRAM if they can go to GTT instead John Brooks
[not found] ` <1498239580-17360-5-git-send-email-john-xq/Ko7C6e2Bl57MIdRCFDg@public.gmane.org>
2017-06-24 18:09 ` Christian König
[not found] ` <0c5064f9-5b84-8833-b410-055b5e2064bf-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-24 18:37 ` John Brooks
2017-06-23 17:39 ` [PATCH 6/9] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS John Brooks
[not found] ` <1498239580-17360-7-git-send-email-john-xq/Ko7C6e2Bl57MIdRCFDg@public.gmane.org>
2017-06-24 18:00 ` Christian König
2017-06-25 1:57 ` John Brooks [this message]
[not found] ` <55ea5e84-0791-5a70-6278-ade83c343a3b-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-26 9:27 ` Michel Dänzer
[not found] ` <6c6fca21-df95-a413-d5eb-c05f1913787b-otUistvHUpPR7s880joybQ@public.gmane.org>
2017-06-26 23:25 ` Marek Olšák
2017-06-23 17:39 ` [PATCH 7/9] drm/amdgpu: Throttle visible VRAM moves separately John Brooks
[not found] ` <1498239580-17360-8-git-send-email-john-xq/Ko7C6e2Bl57MIdRCFDg@public.gmane.org>
2017-06-26 9:44 ` Michel Dänzer
[not found] ` <c132d211-bb7c-1e7d-617a-6f128343a581-otUistvHUpPR7s880joybQ@public.gmane.org>
2017-06-26 22:29 ` John Brooks
2017-06-27 8:25 ` Michel Dänzer
2017-06-23 17:39 ` [PATCH 8/9] drm/amdgpu: Asynchronously move BOs to visible VRAM John Brooks
2017-06-23 21:02 ` [PATCH 0/9] Visible VRAM Management Improvements Felix Kuehling
[not found] ` <82339d2d-481c-ab3f-1590-ab22f0eac371-5C7GfCeVMHo@public.gmane.org>
2017-06-23 23:16 ` John Brooks
2017-06-24 18:20 ` Christian König
[not found] ` <644cf9b4-e22b-eab1-a505-b0e1f9850f82-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-24 21:50 ` John Brooks
2017-06-25 11:54 ` Christian König
2017-06-24 18:07 ` Christian König
[not found] ` <3cd916a7-6734-5eff-b645-66f3ee83f13a-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2017-06-24 18:36 ` John Brooks
2017-06-25 11:31 ` Christian König
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=20170625015719.GA1567@kitsune.fastquake.com \
--to=john@fastquake.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=deathsimple@vodafone.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=michel@daenzer.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).