Re: [PATCH] mm: tracking dirty pages -v6

[Christoph Lameter]

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@xxxxxxx>

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/