From: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
alistair@popple.id.au, aneesh.kumar@linux.vnet.ibm.com,
bsingharora@gmail.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC 1/2] powerpc/mm: Add marker for contexts requiring global TLB invalidations
Date: Sun, 7 May 2017 13:15:55 +0200 [thread overview]
Message-ID: <b62c3873-d9b6-52da-f57f-abc3f382eda6@linux.vnet.ibm.com> (raw)
In-Reply-To: <87efw5yn3o.fsf@concordia.ellerman.id.au>
Le 04/05/2017 à 11:42, Michael Ellerman a écrit :
> Frederic Barrat <fbarrat@linux.vnet.ibm.com> writes:
>
>> Introduce a new 'flags' attribute per context and define its first bit
>> to be a marker requiring all TLBIs for that context to be broadcasted
>> globally. Once that marker is set on a context, it cannot be removed.
>>
>> Such a marker is useful for memory contexts used by devices behind the
>> NPU and CAPP/PSL. The NPU and the PSL keep their own
>> translation cache so they need to see all the TLBIs for those
>> contexts.
>>
>> Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/include/asm/book3s/64/mmu.h | 9 +++++++++
>> arch/powerpc/include/asm/tlb.h | 10 ++++++++--
>> arch/powerpc/mm/mmu_context_book3s64.c | 1 +
>> 3 files changed, 18 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h
>> index 77529a3e3811..7b640ab1cbeb 100644
>> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
>> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
>> @@ -78,8 +78,12 @@ struct spinlock;
>> /* Maximum possible number of NPUs in a system. */
>> #define NV_MAX_NPUS 8
>>
>> +/* Bits definition for the context flags */
>> +#define MM_CONTEXT_GLOBAL_TLBI 1 /* TLBI must be global */
>
> I think I'd prefer MM_GLOBAL_TLBIE, it's shorter and tlbie is the name
> of the instruction so is something people can search for.
OK
>> @@ -164,5 +168,10 @@ extern void radix_init_pseries(void);
>> static inline void radix_init_pseries(void) { };
>> #endif
>>
>> +static inline void mm_context_set_global_tlbi(mm_context_t *ctx)
>> +{
>> + set_bit(MM_CONTEXT_GLOBAL_TLBI, &ctx->flags);
>> +}
>
> set_bit() and test_bit() are non-atomic, and unordered vs other loads
> and stores.
>
> So the caller will need to be careful they have a barrier between this
> and whatever it is they do that creates mappings that might need to be
> invalidated.
Agreed, I missed the barrier. So I need to set the flag, have a write
memory barrier. Then, in the case of cxl, we can attach to the accelerator.
> Similarly on the read side we should have a barrier between the store
> that makes the PTE invalid and the load of the flag.
That one is more subtle, at least to me, but I think I now see what you
mean. With no extra read barrier, we would be exposed to have the
following order:
CPU1 CPU2 device
read flag=>local
set global flag
write barrier
attach
read PTE
update PTE
tlbiel not seen, hence broken
Is that what you meant?
That would mean an extra read barrier for each tlbie.
>
> Which makes me think cxl_ctx_in_use() is buggy :/, hmm. But it's late so
> hopefully I'm wrong :D
Unfortunately, I think you're right. And we're missing the same 2
barriers: a write barrier when cxl increments atomically the use count
before attaching, and a read barrier like above.
Fred
>
>> diff --git a/arch/powerpc/include/asm/tlb.h b/arch/powerpc/include/asm/tlb.h
>> index 609557569f65..bd18ed083011 100644
>> --- a/arch/powerpc/include/asm/tlb.h
>> +++ b/arch/powerpc/include/asm/tlb.h
>> @@ -71,8 +71,14 @@ static inline int mm_is_core_local(struct mm_struct *mm)
>>
>> static inline int mm_is_thread_local(struct mm_struct *mm)
>> {
>> - return cpumask_equal(mm_cpumask(mm),
>> - cpumask_of(smp_processor_id()));
>> + int rc;
>> +
>> + rc = cpumask_equal(mm_cpumask(mm),
>> + cpumask_of(smp_processor_id()));
>> +#ifdef CONFIG_PPC_BOOK3S_64
>> + rc = rc && !test_bit(MM_CONTEXT_GLOBAL_TLBI, &mm->context.flags);
>> +#endif
>
> The ifdef's a bit ugly, but I guess it's not worth putting it in a
> static inline.
>
> I'd be interested to see the generated code for this, and for the
> reverse, ie. putting the test_bit() first, and doing an early return if
> it's true. That way once the bit is set we can just skip the cpumask
> comparison.
>
> cheers
>
next prev parent reply other threads:[~2017-05-07 11:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-03 14:29 [RFC 0/2] powerpc/mm: Mark memory contexts requiring global TLBIs Frederic Barrat
2017-05-03 14:29 ` [RFC 1/2] powerpc/mm: Add marker for contexts requiring global TLB invalidations Frederic Barrat
2017-05-04 6:41 ` Aneesh Kumar K.V
2017-05-04 17:24 ` Frederic Barrat
2017-05-04 7:25 ` Balbir Singh
2017-05-04 9:24 ` Michael Ellerman
2017-05-04 9:42 ` Michael Ellerman
2017-05-07 11:15 ` Frederic Barrat [this message]
2017-05-03 14:29 ` [RFC 2/2] cxl: Mark context requiring global TLBIs Frederic Barrat
2017-05-04 7:39 ` Balbir Singh
2017-05-07 10:41 ` Frederic Barrat
2017-05-05 5:28 ` [RFC 0/2] powerpc/mm: Mark memory contexts " 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=b62c3873-d9b6-52da-f57f-abc3f382eda6@linux.vnet.ibm.com \
--to=fbarrat@linux.vnet.ibm.com \
--cc=alistair@popple.id.au \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=bsingharora@gmail.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
/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).