[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