> We created the range tlb flushes so that architectures have a chance of
> optimizing such operations when possible.
yeah, agreed, we can change it to do the mmu_gather_t thing, and to
optimize that on x86 as well. Nevertheless the fact remains that cache
users were pretty much forced to use a multipage cache unit, which caused
all userspace TLBs to be flushed on x86. Where to draw the line between a
loop of INVLPG and a CR3 flush on x86 is up in the air - i'd say it's at
roughly 8 pages currently, while the x86 TLB flush code only optimizes the
single-page flushes. So you are right that this issue should be separated
from nonlinear mappings.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/