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

Benjamin Herrenschmidt benh at kernel.crashing.org
Fri Aug 25 17:44:39 AEST 2017


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.

Ben.



More information about the Linuxppc-dev mailing list