search for: zap_pte_range

Displaying 20 results from an estimated 30 matches for "zap_pte_range".

2005 Apr 25
3
BUG: xend oopses on munmap of /proc/xen/privcmd
...adinfo=da502000 task=dc8fd550) Stack: db2b41c0 c015a487 00000000 00040004 da4d6b78 b79cd000 b79cd000 b79ccfff c015a5e5 c13eef00 da4d6b78 b79cc000 b79cd000 00000000 00001000 b79cd000 d1d5b134 b79cd000 c015a7e3 c13eef00 d1d5b134 b79cc000 b79cd000 00000000 Call Trace: [<c015a487>] zap_pte_range+0x1a7/0x280 [<c015a5e5>] unmap_page_range+0x85/0xc0 [<c015a7e3>] unmap_vmas+0x1c3/0x290 [<c015f8f5>] unmap_region+0xb5/0x170 [<c015fc87>] do_munmap+0x107/0x150 [<c015fd2a>] sys_munmap+0x5a/0x80 [<c0109493>] syscall_call+0x7/0xb I suspect the oops in set_pa...
2007 Apr 18
1
[PATCH 2/9] 00mm2 pte clear not present.patch
...)) free_swap_and_cache(pte_to_swp_entry(pte)); - 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_...
2005 Jun 23
1
[patch] pin/unpin must flush tlb
...there is a bug in my PAE xenlinux kernel. To me it looks like a generic bug though. I''ve actually trapped into problems with unpin only: A process exits, somewhere in exit_mm() the page tables are unpinned, shortly thereafter the mappings are cleared. While doing so the kernel oopses in zap_pte_range(), on page table write access. Probably due to some stale tlb entry where the page is still tagged read-only. cheers, Gerd Index: linux-2.6.11/arch/xen/i386/mm/pgtable.c =================================================================== --- linux-2.6.11.orig/arch/xen/i386/mm/pgtable.c 2005-06-...
2007 Apr 18
0
[PATCH 3/9] 00mm3 lazy mmu mode hooks.patch
...de(); do { /* @@ -527,6 +528,7 @@ again: progress += 8; } while (dst_pte++, src_pte++, addr += PAGE_SIZE, addr != end); + arch_leave_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...
2006 Jul 03
1
Problem with CentOS 4.3 on kernel and ipvsadm
...2 kernel: flags:0x20000014 mapping:00000000 mapcount:256 count:0 Jul 2 16:40:40 lvs2 kernel: Backtrace: Jul 2 16:40:40 lvs2 kernel: [<c014eaad>] bad_page+0x58/0x89 Jul 2 16:40:40 lvs2 kernel: [<c014f2e1>] free_hot_cold_page+0x5f/0xc8 Jul 2 16:40:40 lvs2 kernel: [<c0159b6a>] zap_pte_range+0x1d9/0x226 Jul 2 16:40:40 lvs2 kernel: [<c0159bf9>] zap_pmd_range+0x42/0x68 Jul 2 16:40:40 lvs2 kernel: [<c0159c58>] unmap_page_range+0x39/0x5f Jul 2 16:40:40 lvs2 kernel: [<c0159d7f>] unmap_vmas+0x101/0x1f8 Jul 2 16:40:40 lvs2 kernel: [<c015ed4a>] exit_mmap+0xb8/0x...
2007 Apr 18
0
[PATCH 2/4] Pte clear optimization.patch
...directly clear the page table entries without notifiying the hypervisor, since all the page tables are about to be freed. So introduce native_pte_clear functions which bypass any paravirt-ops notification. This results in a significant performance win for VMI and removes some indirect calls from zap_pte_range. Note the 3-level paging already had a native_pte_clear function, thus demanding argument conformance and extra args for the 2-level definition. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 1478ce4ec9e3 include/asm-i386/pgtable-2level.h --- a/include/asm-i386/pgtable-2level.h We...
2007 Apr 18
0
[PATCH 2/4] Pte clear optimization.patch
...directly clear the page table entries without notifiying the hypervisor, since all the page tables are about to be freed. So introduce native_pte_clear functions which bypass any paravirt-ops notification. This results in a significant performance win for VMI and removes some indirect calls from zap_pte_range. Note the 3-level paging already had a native_pte_clear function, thus demanding argument conformance and extra args for the 2-level definition. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 1478ce4ec9e3 include/asm-i386/pgtable-2level.h --- a/include/asm-i386/pgtable-2level.h We...
2015 Mar 30
2
[PATCH 0/9] qspinlock stuff -v15
...pgd_alloc |--2.32%-- free_pcppages_bulk |--1.88%-- do_wp_page |--1.77%-- handle_pte_fault |--1.58%-- do_anonymous_page |--1.56%-- rmqueue_bulk.clone.0 |--1.35%-- copy_pte_range |--1.25%-- zap_pte_range |--1.13%-- cache_flusharray |--0.88%-- __pmd_alloc |--0.70%-- wake_up_new_task |--0.66%-- __pud_alloc |--0.59%-- ext4_discard_preallocations --6.53%-- [...] With the qspinlock patch, the perf profile a...
2015 Mar 30
2
[PATCH 0/9] qspinlock stuff -v15
...pgd_alloc |--2.32%-- free_pcppages_bulk |--1.88%-- do_wp_page |--1.77%-- handle_pte_fault |--1.58%-- do_anonymous_page |--1.56%-- rmqueue_bulk.clone.0 |--1.35%-- copy_pte_range |--1.25%-- zap_pte_range |--1.13%-- cache_flusharray |--0.88%-- __pmd_alloc |--0.70%-- wake_up_new_task |--0.66%-- __pud_alloc |--0.59%-- ext4_discard_preallocations --6.53%-- [...] With the qspinlock patch, the perf profile a...
2008 May 31
9
[PATCH 0 of 4] mm+paravirt+xen: add pte read-modify-write abstraction (take 2)
...r fortunately) there aren't very many other areas of the kernel which can really take advantage of this. There's only a couple of other instances of ptep_get_and_clear() in mm/, and they're being used in a similar way; but I don't think they're very performance critical (though zap_pte_range might be interesting). In general, mprotect is rarely a performance bottleneck. But some debugging libraries (such as electric fence) and garbage collectors can be very heavy users of mprotect, and this change could materially benefit them. Thanks, J
2008 May 31
9
[PATCH 0 of 4] mm+paravirt+xen: add pte read-modify-write abstraction (take 2)
...r fortunately) there aren't very many other areas of the kernel which can really take advantage of this. There's only a couple of other instances of ptep_get_and_clear() in mm/, and they're being used in a similar way; but I don't think they're very performance critical (though zap_pte_range might be interesting). In general, mprotect is rarely a performance bottleneck. But some debugging libraries (such as electric fence) and garbage collectors can be very heavy users of mprotect, and this change could materially benefit them. Thanks, J
2008 May 31
9
[PATCH 0 of 4] mm+paravirt+xen: add pte read-modify-write abstraction (take 2)
...r fortunately) there aren't very many other areas of the kernel which can really take advantage of this. There's only a couple of other instances of ptep_get_and_clear() in mm/, and they're being used in a similar way; but I don't think they're very performance critical (though zap_pte_range might be interesting). In general, mprotect is rarely a performance bottleneck. But some debugging libraries (such as electric fence) and garbage collectors can be very heavy users of mprotect, and this change could materially benefit them. Thanks, J
2006 Feb 14
3
Daily Xen-HVM Builds
changeset: 8830:fcc833cbaf82 tag: tip user: kaf24@firebug.cl.cam.ac.uk date: Mon Feb 13 10:41:23 2006 +0100 summary: Return real error code from Xen /dev/mem, not EAGAIN. x460: x86_32: Status: - dom0 boots fine - xend loads fine - single HVM domain loads fine - Multiple HVM domains load fine - destruction of any HVM domain causes dom0 to reboot Issues affecting
2013 Dec 04
5
[PATCH] arm: xen: foreign mapping PTEs are special.
These mappings are in fact special and require special handling in privcmd, which already exists. Failure to mark the PTE as special on arm64 causes all sorts of bad PTE fun. x86 already gets this correct. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: xen-devel@lists.xenproject.org --- arch/arm/xen/enlighten.c |
2007 Apr 18
15
[PATCH 0 of 13] Basic infrastructure patches for a paravirtualized kernel
[ 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
2007 Apr 18
15
[PATCH 0 of 13] Basic infrastructure patches for a paravirtualized kernel
[ 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
2013 Dec 05
7
POD: soft lockups in dom0 kernel
Hi, when creating a bigger (> 50 GB) HVM guest with maxmem > memory we get softlockups from time to time. kernel: [ 802.084335] BUG: soft lockup - CPU#1 stuck for 22s! [xend:31351] I tracked this down to the call of xc_domain_set_pod_target() and further p2m_pod_set_mem_target(). Unfortunately I can this check only with xen-4.2.2 as I don''t have a machine with enough memory for
2008 May 23
6
[PATCH 0 of 4] mm+paravirt+xen: add pte read-modify-write abstraction
...r fortunately) there aren't very many other areas of the kernel which can really take advantage of this. There's only a couple of other instances of ptep_get_and_clear() in mm/, and they're being used in a similar way; but I don't think they're very performance critical (though zap_pte_range might be interesting). In general, mprotect is rarely a performance bottleneck. But some debugging libraries (such as electric fence) and garbage collectors can be very heavy users of mprotect, and this change could materially benefit them. Thanks, J
2008 May 23
6
[PATCH 0 of 4] mm+paravirt+xen: add pte read-modify-write abstraction
...r fortunately) there aren't very many other areas of the kernel which can really take advantage of this. There's only a couple of other instances of ptep_get_and_clear() in mm/, and they're being used in a similar way; but I don't think they're very performance critical (though zap_pte_range might be interesting). In general, mprotect is rarely a performance bottleneck. But some debugging libraries (such as electric fence) and garbage collectors can be very heavy users of mprotect, and this change could materially benefit them. Thanks, J
2008 May 23
6
[PATCH 0 of 4] mm+paravirt+xen: add pte read-modify-write abstraction
...r fortunately) there aren't very many other areas of the kernel which can really take advantage of this. There's only a couple of other instances of ptep_get_and_clear() in mm/, and they're being used in a similar way; but I don't think they're very performance critical (though zap_pte_range might be interesting). In general, mprotect is rarely a performance bottleneck. But some debugging libraries (such as electric fence) and garbage collectors can be very heavy users of mprotect, and this change could materially benefit them. Thanks, J