search for: zap_pte_rang

...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_p...

...)) 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...

...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...

...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_wor...

...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/0...

...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 W...

...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 W...

...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...

...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...

...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

...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

...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

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

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 |

[ 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

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

...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

...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

...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