[PATCH 5/6] powerpc/mm: Optimize detection of thread local mm's

Frederic Barrat fbarrat at linux.vnet.ibm.com
Fri Aug 25 18:03:54 AEST 2017



Le 25/08/2017 à 09:44, Benjamin Herrenschmidt a écrit :
> On Fri, 2017-08-25 at 06:53 +0200, Frederic Barrat wrote:
>>
>> Le 24/08/2017 à 20:47, Benjamin Herrenschmidt a écrit :
>>> On Thu, 2017-08-24 at 18:40 +0200, Frederic Barrat wrote:
>>>>
>>>> The decrementing part is giving me troubles, and I think it makes sense:
>>>> if I decrement the counter when detaching the context from the capi
>>>> card, then the next TLBIs for the memory context may be back to local.
>>>
>>> Yes, you need to flush the CAPI TLB first.
>>>
>>>> So when the process exits, the NPU wouldn't get the associated TLBIs,
>>>> which spells trouble the next time the same memory context ID is reused.
>>>> I believe this the cause of the problem I'm seeing. As soon as I keep
>>>> the TLBIs global, even after I detach from the capi adapter, everything
>>>> is fine.
>>>>
>>>> Does it sound right?
>>>>
>>>> So to keep the checks minimal in mm_is_thread_local(), to just checking
>>>> the active_cpus count, I'm thinking of introducing a "copro enabled" bit
>>>> on the context, so that we can increment active_cpus only once. And
>>>> never decrement it.
>>>
>>> You can decrement if you flush. Don't you have MMIOs to do directed
>>> flushes ?
>>
>> That's for the nMMU. Last I heard, we don't have MMIOs to flush anything
>> on the nMMU.
>>
>> Side note: for the PSL, we do have MMIOs to flush, but they were
>> perceived as useful only for debug and we don't rely on them, precisely
>> because the nMMU would fall out of sync, so we have to rely on broadcast.
> 
> Well, you can always do a broadcast tlbi to flush the whole PID if you
> decrement... that shouldn't be a very frequent operation.

Arg, yes!
Thanks!

   Fred




More information about the Linuxppc-dev mailing list