Currently mprotect (and other operations) on paravirt domains have very bad scalability. This is no surprise, since all writable pagetable operations happen under the domain big lock, allowing only one VCPU at a time to fill in or change PTEs. This seems an unnecessary restriction, since all the writable pagetable code does most of the time is atomic updates to page table entries that are already in place. I do not understand what we need to protect against, except of course page table pages changing status (new page table pages being added, old page table pages becoming writable again) while handling a writable pagetable fault. Does anybody see issues with putting all of the writable pagetable operations under a read-write lock, with the code paths that change page table entries (mostly the fault handling) taking the lock in read mode, and the code paths that change the status of pages taking the lock in write mode? That way we can guarantee that the writable page table pages do not change status while handling a fault (and we get concurrency), blocking out the write fault handling only while new page table pages are being created or destroyed. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 7/12/07 17:06, "Rik van Riel" <riel@redhat.com> wrote:> Does anybody see issues with putting all of the writable pagetable > operations under a read-write lock, with the code paths that change > page table entries (mostly the fault handling) taking the lock in > read mode, and the code paths that change the status of pages taking > the lock in write mode? > > That way we can guarantee that the writable page table pages do not > change status while handling a fault (and we get concurrency), blocking > out the write fault handling only while new page table pages are being > created or destroyed.I think we can probably just as easily strip out the big lock entirely from the critical paths. It''s not really needed much these days. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 07 Dec 2007 17:47:40 +0000 Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> On 7/12/07 17:06, "Rik van Riel" <riel@redhat.com> wrote: > > > Does anybody see issues with putting all of the writable pagetable > > operations under a read-write lock, with the code paths that change > > page table entries (mostly the fault handling) taking the lock in > > read mode, and the code paths that change the status of pages taking > > the lock in write mode? > > > > That way we can guarantee that the writable page table pages do not > > change status while handling a fault (and we get concurrency), blocking > > out the write fault handling only while new page table pages are being > > created or destroyed. > > I think we can probably just as easily strip out the big lock entirely from > the critical paths. It''s not really needed much these days."not needed much" makes me kind of nervous :) Exactly what do we still need to protect against? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 7/12/07 17:53, "Rik van Riel" <riel@redhat.com> wrote:>> I think we can probably just as easily strip out the big lock entirely from >> the critical paths. It''s not really needed much these days. > > "not needed much" makes me kind of nervous :) > > Exactly what do we still need to protect against?The main thing right now is update_va_mapping() goes at the linear map, and has to avoid races where a pte is being deconstructed but has not yet been flushed from the linear map. If we change the implementation of update_va_mapping() then I think the biglock can fall away. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel