search for: ptent

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, ptent); sequence in mm/mprotect.c:change_pte_range(). This is bad for Xen for two reasons: 1: ptep_get_and_clear() ends up being a xchg on the pte. Since the pte page is read-o...

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, ptent); sequence in mm/mprotect.c:change_pte_range(). This is bad for Xen for two reasons: 1: ptep_get_and_clear() ends up being a xchg on the pte. Since the pte page is read-o...

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, ptent); sequence in mm/mprotect.c:change_pte_range(). This is bad for Xen for two reasons: 1: ptep_get_and_clear() ends up being a xchg on the pte. Since the pte page is read-o...

...te-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), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte, ptent); sequence in mm/mprotect.c:change_pte_range(). This is bad for Xen for two reasons: 1: ptep_get_and_clear() ends up being a xchg on the pte. Since the pte page is read-o...

...te-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), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte, ptent); sequence in mm/mprotect.c:change_pte_range(). This is bad for Xen for two reasons: 1: ptep_get_and_clear() ends up being a xchg on the pte. Since the pte page is read-o...

...te-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), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte, ptent); sequence in mm/mprotect.c:change_pte_range(). This is bad for Xen for two reasons: 1: ptep_get_and_clear() ends up being a xchg on the pte. Since the pte page is read-o...

...2.6/mm/mprotect.c linux-2.6-patched/mm/mprotect.c --- linux-2.6/mm/mprotect.c 2006-09-01 12:49:33.000000000 +0200 +++ linux-2.6-patched/mm/mprotect.c 2006-09-01 12:50:24.000000000 +0200 @@ -52,6 +52,7 @@ static void change_pte_range(struct mm_s */ if (dirty_accountable && pte_dirty(ptent)) ptent = pte_mkwrite(ptent); + page_check_writable(pte_page(ptent), ptent); set_pte_at(mm, addr, pte, ptent); lazy_mmu_prot_update(ptent); #ifdef CONFIG_MIGRATION diff -urpN linux-2.6/mm/page_alloc.c linux-2.6-patched/mm/page_alloc.c --- linux-2.6/mm/page_alloc.c 2006-09-01 12:50:2...

...2.6/mm/mprotect.c linux-2.6-patched/mm/mprotect.c --- linux-2.6/mm/mprotect.c 2006-09-01 12:49:33.000000000 +0200 +++ linux-2.6-patched/mm/mprotect.c 2006-09-01 12:50:24.000000000 +0200 @@ -52,6 +52,7 @@ static void change_pte_range(struct mm_s */ if (dirty_accountable && pte_dirty(ptent)) ptent = pte_mkwrite(ptent); + page_check_writable(pte_page(ptent), ptent); set_pte_at(mm, addr, pte, ptent); lazy_mmu_prot_update(ptent); #ifdef CONFIG_MIGRATION diff -urpN linux-2.6/mm/page_alloc.c linux-2.6-patched/mm/page_alloc.c --- linux-2.6/mm/page_alloc.c 2006-09-01 12:50:2...

...- pte_clear(mm, addr, ptep); + pte_clear_not_present_full(mm, addr, ptep, 0); } return !!page; } =================================================================== --- a/mm/memory.c +++ b/mm/memory.c @@ -689,7 +689,7 @@ static unsigned long zap_pte_range(struc continue; if (!pte_file(ptent)) free_swap_and_cache(pte_to_swp_entry(ptent)); - pte_clear_full(mm, addr, pte, tlb->fullmm); + pte_clear_not_present_full(mm, addr, pte, tlb->fullmm); } while (pte++, addr += PAGE_SIZE, (addr != end && *zap_work > 0)); add_mm_rss(mm, file_rss, anon_rss);

...inux/slab.h> +#include <linux/spinlock.h> +#include <linux/interrupt.h> + +#include <asm/hv_vm.h> + +static DEFINE_MUTEX(hvvm_lock); + +static DECLARE_BITMAP(hvvm_avail_pages, NR_HV_PAGES); + + +static void hvvm_pte_unmap(pmd_t *pmd, unsigned long addr) +{ + pte_t *pte; + pte_t ptent; + + pte = pte_offset_kernel(pmd, addr); + ptent = ptep_get_and_clear(&init_mm, addr, pte); + WARN_ON(!pte_none(ptent) && !pte_present(ptent)); +} + +static inline void hvvm_pmd_unmap(pud_t *pud, unsigned long addr) +{ + pmd_t *pmd; + + pmd = pmd_offset(pud, addr); + if (pmd_none_or_cle...

...inux/slab.h> +#include <linux/spinlock.h> +#include <linux/interrupt.h> + +#include <asm/hv_vm.h> + +static DEFINE_MUTEX(hvvm_lock); + +static DECLARE_BITMAP(hvvm_avail_pages, NR_HV_PAGES); + + +static void hvvm_pte_unmap(pmd_t *pmd, unsigned long addr) +{ + pte_t *pte; + pte_t ptent; + + pte = pte_offset_kernel(pmd, addr); + ptent = ptep_get_and_clear(&init_mm, addr, pte); + WARN_ON(!pte_none(ptent) && !pte_present(ptent)); +} + +static inline void hvvm_pmd_unmap(pud_t *pud, unsigned long addr) +{ + pmd_t *pmd; + + pmd = pmd_offset(pud, addr); + if (pmd_none_or_cle...

...eave_lazy_mmu_mode(); spin_unlock(src_ptl); pte_unmap_nested(src_pte - 1); add_mm_rss(dst_mm, rss[0], rss[1]); @@ -628,6 +630,7 @@ static unsigned long zap_pte_range(struc int anon_rss = 0; pte = pte_offset_map_lock(mm, pmd, addr, &ptl); + arch_enter_lazy_mmu_mode(); do { pte_t ptent = *pte; if (pte_none(ptent)) { @@ -694,6 +697,7 @@ static unsigned long zap_pte_range(struc } while (pte++, addr += PAGE_SIZE, (addr != end && *zap_work > 0)); add_mm_rss(mm, file_rss, anon_rss); + arch_leave_lazy_mmu_mode(); pte_unmap_unlock(pte - 1, ptl); return addr; @@...

I''m sure everyone has seen the drop of VMI patches for Linux at this point, but just in case, the link is included below. I''ve read this version of the VMI spec and have made my way through most of the patches. While I wasn''t really that impressed with the first spec wrt Xen, the second version seems to be much more palatable. Specifically, the code inlining and

Greetings, after Carsten pitched CMM2 on the kvm mini summit here is a repost of version 5 of the guest page hinting patches. The code is still the same but has been adapted to the latest git level. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.

Greetings, after Carsten pitched CMM2 on the kvm mini summit here is a repost of version 5 of the guest page hinting patches. The code is still the same but has been adapted to the latest git level. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.

[ 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

After way to many months here is the fifth version of the guest page hinting patches. Compared to version four a few improvements have been added: - Avoid page_host_discards() calls outside of page-states.h - The discard list is now implemented via the page_free_discarded hook and architecture specific code. - PG_state_change page flag has been replaced with architecture specficic

After way to many months here is the fifth version of the guest page hinting patches. Compared to version four a few improvements have been added: - Avoid page_host_discards() calls outside of page-states.h - The discard list is now implemented via the page_free_discarded hook and architecture specific code. - PG_state_change page flag has been replaced with architecture specficic

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