Messages in this thread Patch in this message |  | | | Date | Thu, 8 Jun 2006 09:53:47 -0700 (PDT) | | From | Christoph Lameter <> | | Subject | Re: [PATCH] mm: tracking dirty pages -v6 |
| |
1. The case that a vma is shared is not likely.
2. Typo fix in mmap.c
3. This may be a bit controversial but it does not seem to make sense to use the update_mmu_cache macro when we reuse the page. We are only fiddling around with the protections, the dirty and accessed bits.
With the call to update_mmu_cache the way of using the macros would be different from mprotect() and page_mkclean(). I'd rather have everything work the same way. If this breaks on some arches then also mprotect and page_mkclean() are broken. The use of mprotect() is rare, we may have breakage in some arches that we just have not seen yet.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Index: linux-2.6/mm/memory.c =================================================================== --- linux-2.6.orig/mm/memory.c 2006-06-08 09:12:13.000000000 -0700 +++ linux-2.6/mm/memory.c 2006-06-08 09:50:17.000000000 -0700 @@ -1452,7 +1452,7 @@ static int do_wp_page(struct mm_struct * if (!old_page) goto gotten; - if (vma->vm_flags & VM_SHARED) { + if (unlikely(vma->vm_flags & VM_SHARED)) { reuse = 1; dirty_page = old_page; get_page(dirty_page); @@ -1466,7 +1466,6 @@ static int do_wp_page(struct mm_struct * entry = pte_mkyoung(orig_pte); entry = maybe_mkwrite(pte_mkdirty(entry), vma); ptep_set_access_flags(vma, address, page_table, entry, 1); - update_mmu_cache(vma, address, entry); lazy_mmu_prot_update(entry); ret |= VM_FAULT_WRITE; goto unlock; Index: linux-2.6/mm/mmap.c =================================================================== --- linux-2.6.orig/mm/mmap.c 2006-06-08 09:15:54.000000000 -0700 +++ linux-2.6/mm/mmap.c 2006-06-08 09:17:41.000000000 -0700 @@ -1092,7 +1092,7 @@ munmap_back: * f_op->mmap() - modifies vm_page_prot; but will not reset * from vm_flags. * - * Hence between the two calls (here) it is save to modify + * Hence between the two calls (here) it is safe to modify * vm_page_prot depending on backing_dev_info capabilities. * * shmem_backing_dev_info does have BDI_CAP_NO_ACCT_DIRTY. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |