From: Alistair Popple <alistair@popple.id.au>
To: Mark Hairgrove <mhairgrove@nvidia.com>
Cc: linuxppc-dev@lists.ozlabs.org, Reza Arbab <arbab@us.ibm.com>
Subject: Re: [PATCH 2/3] powerpc/powernv/npu: Use size-based ATSD invalidates
Date: Wed, 03 Oct 2018 12:27:14 +1000 [thread overview]
Message-ID: <3711069.TlgilHPQgk@new-mexico> (raw)
In-Reply-To: <alpine.DEB.2.00.1810021750110.16676@mdh-linux64-2.nvidia.com>
> >
> > We also support 4K page sizes on PPC. If I am not mistaken this means every ATSD
> > would invalidate the entire GPU TLB for a the given PID on those systems. Could
> > we change the above check to `if (size <= PAGE_64K)` to avoid this?
>
> PPC supports 4K pages but the GPU ATS implementation does not. For that
> reason I didn't bother handling invalidates smaller than 64K. I'll add a
> comment on that.
Interesting, I was not aware of that limitation. Do you know if it is a
SW/driver limitation or a HW limitation?
> I don't know that this requirement is enforced anywhere though. I could
> add a PAGE_SIZE == 64K check to pnv_npu2_init_context if you think it
> would be useful.
Given it's a static kernel build parameter perhaps it makes more sense to do the
check as part of the driver build in a conftest rather than a runtime failure?
> >
> > > + atsd_start = start;
> >
> > Which would also require:
> >
> > atsd_start = ALIGN_DOWN(start, PAGE_64K);
> >
> > > + atsd_psize = MMU_PAGE_64K;
> > > + } else if (ALIGN_DOWN(start, PAGE_2M) == ALIGN_DOWN(end, PAGE_2M)) {
> >
> > Wouldn't this lead to under invalidation in ranges which happen to cross a 2M
> > boundary? For example invalidating a 128K (ie. 2x64K pages) range with start ==
> > 0x1f0000 and end == 0x210000 would result in an invalidation of the range 0x0 -
> > 0x200000 incorrectly leaving 0x200000 - 0x210000 in the GPU TLB.
>
> In this example:
> start 0x1f0000
> size 0x020000
> end (start + size - 1) 0x20ffff
> ALIGN_DOWN(start, PAGE_2M) 0x000000
> ALIGN_DOWN(end, PAGE_2M) 0x200000
>
> Since ALIGN_DOWN(start, PAGE_2M) != ALIGN_DOWN(end, PAGE_2M), the
> condition fails and we move to the 1G clause. Then
> ALIGN_DOWN(start, PAGE_1G) == ALIGN_DOWN(end, PAGE_1G) == 0, so we
> invalidate the range [0, 1G).
Oh yeah, sorry that makes sense and looks good to me.
- Alistair
next prev parent reply other threads:[~2018-10-03 2:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-27 23:23 [PATCH 0/3] powerpc/powernv/npu: Improve ATSD invalidation overhead Mark Hairgrove
2018-09-27 23:23 ` [PATCH 1/3] powerpc/powernv/npu: Reduce eieio usage when issuing ATSD invalidates Mark Hairgrove
2018-10-02 7:23 ` Alistair Popple
2018-09-27 23:23 ` [PATCH 2/3] powerpc/powernv/npu: Use size-based " Mark Hairgrove
2018-10-02 7:11 ` Alistair Popple
2018-10-03 1:10 ` Mark Hairgrove
2018-10-03 2:27 ` Alistair Popple [this message]
2018-10-03 18:33 ` Mark Hairgrove
2018-09-27 23:23 ` [PATCH 3/3] powerpc/powernv/npu: Remove atsd_threshold debugfs setting Mark Hairgrove
2018-10-02 7:12 ` Alistair Popple
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=3711069.TlgilHPQgk@new-mexico \
--to=alistair@popple.id.au \
--cc=arbab@us.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhairgrove@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox