On Fri, 1 Feb 2008, Andrea Arcangeli wrote: > GRU. Thanks to the PT lock this remains a totally obviously safe > design and it requires zero additional locking anywhere (nor linux VM, > nor in the mmu notifier methods, nor in the KVM/GRU page fault).
Na. I would not be so sure about having caught all the issues yet... > Sure you can do invalidate_range_start/end for more than 2M(/4M on > 32bit) max virtual ranges. But my approach that averages the fixed > mmu_lock cost already over 512(/1024) ptes will make any larger > "range" improvement not strongly measurable anymore given to do that > you have to add locking as well and _surely_ decrease the GRU > scalability with tons of threads and tons of cpus potentially making > GRU a lot slower _especially_ on your numa systems. The trouble is that the invalidates are much more expensive if you have to send theses to remote partitions (XPmem). And its really great if you can simple tear down everything. Certainly this is a significant improvement over the earlier approach but you still have the invalidate_page calls in ptep_clear_flush. So they fire needlessly? Serializing access in the device driver makes sense and comes with additional possiblity of not having to increment page counts all the time. So you trade one cacheline dirtying for many that are necessary if you always increment the page count. How does KVM insure the consistency of the shadow page tables? Atomic ops? The GRU has no page table on its own. It populates TLB entries on demand using the linux page table. There is no way it can figure out when to drop page counts again. The invalidate calls are turned directly into tlb flushes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
