On Mon, 27 Aug 2018 18:09:50 +1000 Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 2018-08-27 at 18:04 +1000, Nicholas Piggin wrote: > > > Yes.. I see that. tlb_remove_check_page_size_change() really is a rather > > > ugly thing, it can cause loads of TLB flushes. Do you really _have_ to > > > do that? The way ARM and x86 work is that using INVLPG in a 4K stride is > > > still correct for huge pages, inefficient maybe, but so is flushing > > > every other page because 'sparse' transparant-huge-pages. > > > > It could do that. It requires a tlbie that matches the page size, > > so it means 3 sizes. I think possibly even that would be better > > than current code, but we could do better if we had a few specific > > fields in there. > > More tlbies ? With the cost of the broadasts on the fabric ? I don't > think so.. or I'm not understanding your point... More tlbies are no good, but there will be some places where it works out much better (and fewer tlbies). Worst possible case for current code is a big unmap with lots of scattered page sizes. We _should_ get that with just a single PID flush at the end, but what we will get today is a bunch of PID and VA flushes. I don't propose doing that though, I'd rather be explicit about tracking start and end range of each page size. Still not "optimal" but neither is existing single range for sparse mappings... anyway it will need to be profiled, but my point is we don't really fit exactly what x86/arm want. Thanks, Nick
