search for: oldpte

...14 @@ * This routine directly affects the fork perf for a process. */ void -pmap_new_proc(struct proc *p) +pmap_new_proc(p) + struct proc *p; { - int i; + int i, updateneeded; vm_object_t upobj; - vm_page_t m, ma[UPAGES]; - vm_offset_t up; + vm_page_t m; + struct user *up; + unsigned *ptek, oldpte; /* * allocate object for the upages @@ -844,19 +863,22 @@ } /* get a kernel virtual address for the UPAGES for this proc */ - if ((up = (vm_offset_t) p->p_addr) == 0) { - up = kmem_alloc_nofault(kernel_map, UPAGES * PAGE_SIZE); - if (up == 0) + if ((up = p->p_addr) == NULL) {...

...); return 0; } =================================================================== --- a/mm/mprotect.c +++ b/mm/mprotect.c @@ -34,6 +34,7 @@ static void change_pte_range(struct mm_s spinlock_t *ptl; pte = pte_offset_map_lock(mm, pmd, addr, &ptl); + arch_enter_lazy_mmu_mode(); do { oldpte = *pte; if (pte_present(oldpte)) { @@ -70,6 +71,7 @@ static void change_pte_range(struct mm_s } } while (pte++, addr += PAGE_SIZE, addr != end); + arch_leave_lazy_mmu_mode(); pte_unmap_unlock(pte - 1, ptl); } =================================================================== --- a/m...

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

[ REPOST: Apologies to anyone who has seen this before. It didn't make it onto any of the lists it should have. -J ] Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. For the most part, these patches do nothing or very little. The patches should

[ REPOST: Apologies to anyone who has seen this before. It didn't make it onto any of the lists it should have. -J ] Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. For the most part, these patches do nothing or very little. The patches should

At OLS I gave a talk on some of the Xen scalability inhibitors, and one of these was writable page tables. We went over why the feature does not scale, but just as important, we found that the uniprocessor case does not provide any advantage either. These tests were done on x86_64, so I wanted to run the 1-way test on 32 bit to show the same problem. So, I have run with writable PTs and