Re: tlb_gather_mmu() and semantics of "fullmm"

Benjamin Herrenschmidt
2009-03-27T03:17:24Z

> Side note: this means that CPU's that do speculative TLB fills may still
> touch the user entries.

Ok. That's what I wasn't sure of. It's fortunately not the case on SW
loaded TLBs so I may still do some optimisations on these guys.

> They won't _care_ about what they get, though. So
> you should be able to do any optimizations you want, as long as it doesn't
> cause machine checks or similar (ie another CPU doing a speculative access
> and then being really unhappy about a totally invalid page table entry).

Right.

> > Although it looks as if there's a TLB flush at the end of every batch,
> > isn't that deceptive (on x86 anyway)?
>
> You need to. Again. Even on that CPU the TLB may have gotten re-loaded
> speculatively, even if nothing _meant_ to touch user pages.
>
> So you can't just flush the TLB once, and then expect that since you
> flushed it, and nothing else accessed those user addresses, you don't need
> to flush it again.
>
> And doing things the other way around - only flushing once at the end - is
> incorrect because the whole point is that we can only free the page
> directory once we've flushed all the translations that used it. So we need
> to flush before the real release, and we need to flush after we've
> unmapped everything. Thus the repeated flushes.
>
> It shouldn't be that costly, since kernel mappings should be marked
> global.

I was talking about the freeing of the individual pages, not the page
tables per-se, but yes, I see that the problem is there too.

I'll do some experiments on embedded stuffs here and see if it's worth
doing things differently. I'm trying to avoid too many IPIs typically.
The problem with our TLBs is that they cache multiple contexts, and so
they may still hold translations for contexts not currently active,
-but- we really don't need to do heavy synchronisation to flush those.

Cheers,
Ben.