From: Nicholas Piggin <nicholas.piggin@gmail.com>
To: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Cc: mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org,
benh@kernel.crashing.org, andrew.donnellan@au1.ibm.com,
clombard@linux.vnet.ibm.com, vaibhav@linux.vnet.ibm.com,
alistair@popple.id.au
Subject: Re: [PATCH v3 2/2] cxl: Enable global TLBIs for cxl contexts
Date: Fri, 8 Sep 2017 16:56:24 +1000 [thread overview]
Message-ID: <20170908165624.22dca915@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <20170903181513.29635-2-fbarrat@linux.vnet.ibm.com>
On Sun, 3 Sep 2017 20:15:13 +0200
Frederic Barrat <fbarrat@linux.vnet.ibm.com> wrote:
> The PSL and nMMU need to see all TLB invalidations for the memory
> contexts used on the adapter. For the hash memory model, it is done by
> making all TLBIs global as soon as the cxl driver is in use. For
> radix, we need something similar, but we can refine and only convert
> to global the invalidations for contexts actually used by the device.
>
> The new mm_context_add_copro() API increments the 'active_cpus' count
> for the contexts attached to the cxl adapter. As soon as there's more
> than 1 active cpu, the TLBIs for the context become global. Active cpu
> count must be decremented when detaching to restore locality if
> possible and to avoid overflowing the counter.
>
> The hash memory model support is somewhat limited, as we can't
> decrement the active cpus count when mm_context_remove_copro() is
> called, because we can't flush the TLB for a mm on hash. So TLBIs
> remain global on hash.
Sorry I didn't look at this earlier and just wading in here a bit, but
what do you think of using mmu notifiers for invalidating nMMU and
coprocessor caches, rather than put the details into the host MMU
management? npu-dma.c already looks to have almost everything covered
with its notifiers (in that it wouldn't have to rely on tlbie coming
from host MMU code).
This change is not too bad today, but if we get to more complicated
MMU/nMMU TLB management like directed invalidation of particular units,
then putting more knowledge into the host code will end up being
complex I think.
I also want to also do optimizations on the core code that assumes we
only have to take care of other CPUs, e.g.,
https://patchwork.ozlabs.org/patch/811068/
Or, another example, directed IPI invalidations from the mm_cpumask
bitmap.
I realize you want to get something merged! For the merge window and
backports this seems fine. I think it would be nice soon afterwards to
get nMMU knowledge out of the core code... Though I also realize with
our tlbie instruction that does everything then it may be tricky to
make a really optimal notifier.
Thanks,
Nick
>
> Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> Fixes: f24be42aab37 ("cxl: Add psl9 specific code")
> ---
> Changelog:
> v3: don't decrement active cpus count with hash, as we don't know how to flush
> v2: Replace flush_tlb_mm() by the new flush_all_mm() to flush the TLBs
> and PWCs (thanks to Ben)
next prev parent reply other threads:[~2017-09-08 6:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-03 18:15 [PATCH v3 1/2] powerpc/mm: Export flush_all_mm() Frederic Barrat
2017-09-03 18:15 ` [PATCH v3 2/2] cxl: Enable global TLBIs for cxl contexts Frederic Barrat
2017-09-08 6:56 ` Nicholas Piggin [this message]
2017-09-08 7:34 ` Frederic Barrat
2017-09-08 10:54 ` Nicholas Piggin
2017-09-08 11:18 ` Nicholas Piggin
2017-09-13 3:53 ` Alistair Popple
2017-09-13 3:58 ` Alistair Popple
2017-09-13 4:04 ` [PATCH v3 1/2] powerpc/mm: Export flush_all_mm() Alistair Popple
2017-09-13 8:34 ` Frederic Barrat
2017-10-05 4:21 ` [v3,1/2] " Michael Ellerman
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=20170908165624.22dca915@roar.ozlabs.ibm.com \
--to=nicholas.piggin@gmail.com \
--cc=alistair@popple.id.au \
--cc=andrew.donnellan@au1.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=clombard@linux.vnet.ibm.com \
--cc=fbarrat@linux.vnet.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=vaibhav@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).