On 11/14/2012 01:01 PM, Linus Torvalds wrote:
But even *more* aggressively, how about looking at - not flushing the TLB at all if the bits become more permissive (taking the TLB micro-fault and letting the CPU just update it on its own)
This seems like a good idea. Additionally, we may be able to get away with not modifying the PTEs if the bits become more permissive. We can just let handle_pte_fault update the bits to match the VMA permissions. That way we may be able to save a fair amount of scanning and pte manipulation for eg. JVMs that manipulate the same range of memory repeatedly in the garbage collector. I do not know whether that would be worthwhile, but it sounds like something that may be worth a try...
- even *more* aggressive: if the bits become strictly more restrictive, how about not flushing the TLB at all, *and* not even changing the page tables, and just teaching the page fault code to do it lazily at fault time?
How can we do that in a safe way? Unless we change the page tables, and flush the TLBs before returning to userspace, the mprotect may not take effect for an arbitrarily large period of time. If we do not change the page tables, we should also not incur any page faults, so the fault code would never run to "do it lazily". Am I misreading what you propose?
Now, the "change protections lazily" might actually be a huge performance problem with the page fault overhead dwarfing any TLB flush costs, but we don't really know, do we? It might be worth trying out.
-- All rights reversed -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>