On Mon, 2018-08-27 at 18:04 +1000, Nicholas Piggin wrote: > 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.
Would it cause a noticeable overhead to keep track of which page sizes were removed, and to simply flush the whole TLB in the (unlikely?) event that multiple page sizes were removed in the same munmap? Once the unmap is so large that multiple page sizes were covered, you may already be looking at so many individual flush operations that a full flush might be faster. Is there a point on PPC where simply flushing the whole TLB, and having other things be reloaded later, is faster than flushing every individual page mapping that got unmapped? -- All Rights Reversed.
signature.asc
Description: This is a digitally signed message part
