Re: Page fault scalability patch V18: Drop first acquisition of ptl

From: Christoph Lameter
Date: Fri Mar 04 2005 - 11:56:21 EST


On Thu, 3 Mar 2005, Andrew Morton wrote:

> A fix would be to restore the get_page() if CONFIG_DEBUG_PAGEALLOC. Not
> particularly glorious..

Here is the unglorious solution. It also requies that
CONFIG_ATOMIC_TABLE_OPS not be used together with CONFIG_DEBUG_PAGEALLOC
(handled in the following patch):

---------------------------------------------------------------------------

We do a page_cache_get in do_wp_page but we check the pte for changes later.

So why do a page_cache_get at all? Do the copy and maybe copy garbage and
if the pte was changed forget about it. This avoids having to keep state
on the page copied from.

However this does not work for CONFIG_DEBUG_PAGEALLOC. So leave these in
if debugging is enabled. This also means that the following patch will not
allow setting CONFIG_ATOMIC_TABLE_OPS if CONFIG_DEBUG_PAGEALLOC is
selected.

Signed-off-by: Christoph Lameter <clameter@xxxxxxx>

Index: linux-2.6.11/mm/memory.c
===================================================================
--- linux-2.6.11.orig/mm/memory.c 2005-03-04 08:25:22.000000000 -0800
+++ linux-2.6.11/mm/memory.c 2005-03-04 08:26:30.000000000 -0800
@@ -1318,8 +1318,14 @@ static int do_wp_page(struct mm_struct *
/*
* Ok, we need to copy. Oh, well..
*/
+#ifdef CONFIG_DEBUG_PAGEALLOC
+ /* For debugging we need to get the page otherwise
+ * the pte for this kernel page may vanish while
+ * we copy the page.
+ */
if (!PageReserved(old_page))
page_cache_get(old_page);
+#endif
spin_unlock(&mm->page_table_lock);

if (unlikely(anon_vma_prepare(vma)))
@@ -1358,12 +1364,16 @@ static int do_wp_page(struct mm_struct *
}
pte_unmap(page_table);
page_cache_release(new_page);
+#ifdef CONFIG_DEBUG_PAGEALLOC
page_cache_release(old_page);
+#endif
spin_unlock(&mm->page_table_lock);
return VM_FAULT_MINOR;

no_new_page:
+#ifdef CONFIG_DEBUG_PAGEALLOC
page_cache_release(old_page);
+#endif
return VM_FAULT_OOM;
}

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