Re: page fault scalability patch V16 [3/4]: Drop page_table_lock inhandle_mm_fault

[Christoph Lameter]

On Wed, 2 Feb 2005, Nick Piggin wrote:

> > The unmapping in rmap.c would change the pte. This would be discovered
> > after acquiring the spinlock later in do_wp_page. Which would then lead to
> > the operation being abandoned.
> Oh yes, but suppose your page_cache_get is happening at the same time
> as free_pages_check, after the page gets freed by the scanner? I can't
> actually think of anything that would cause a real problem (ie. not a
> debug check), off the top of my head. But can you say there _isn't_
> anything?
>
> Regardless, it seems pretty dirty to me. But could possibly be made
> workable, of course.

Would it make you feel better if we would move the spin_unlock back to the
prior position? This would ensure that the fallback case is exactly the
same.

Index: linux-2.6.10/mm/memory.c
===================================================================
--- linux-2.6.10.orig/mm/memory.c	2005-01-31 08:59:07.000000000 -0800
+++ linux-2.6.10/mm/memory.c	2005-02-01 10:55:30.000000000 -0800
@@ -1318,7 +1318,6 @@ static int do_wp_page(struct mm_struct *
 		}
 	}
 	pte_unmap(page_table);
-	page_table_atomic_stop(mm);

 	/*
 	 * Ok, we need to copy. Oh, well..
@@ -1326,6 +1325,7 @@ static int do_wp_page(struct mm_struct *
 	if (!PageReserved(old_page))
 		page_cache_get(old_page);

+	page_table_atomic_stop(mm);
 	if (unlikely(anon_vma_prepare(vma)))
 		goto no_new_page;
 	if (old_page == ZERO_PAGE(address)) {
-
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/