On Wed, Aug 04, 2021 at 04:39:44PM +1000, Nicholas Piggin wrote: > For that matter, I wonder if we shouldn't do something like this > (untested) so the low level batch flush has visibility to the high > level flush range. > > x86 could use this too AFAIKS, just needs to pass the range a bit > further down, but in practice I'm not sure it would ever really > matter for them because the 2MB level exceeds the single page flush > ceiling for 4k pages unlike powerpc with 64k pages. But in corner > cases where the unmap crossed a bunch of small vmas or the ceiling > was increased then in theory it could be of use. x86 can do single invalidates for 2M pages if that's the only type encountered in the range, at which point we can do 33*2M = 66M, which is well below the 1G range for the next level of huge. > Subject: [PATCH v1] mm/mmu_gather: provide archs with the entire range that is > to be flushed, not just the particular gather > > This allows archs to optimise flushing heuristics better, in the face of > flush operations forcing smaller flush batches. For example, an > architecture may choose a more costly per-page invalidation for small > ranges of pages with the assumption that the full TLB flush cost would > be more expensive in terms of refills. However if a very large range is > forced into flushing small ranges, the faster full-process flush may > have been the better choice. What is splitting up the flushes for you? That page_size power-special?
