[patch 1] Xen core patch : ptep_establish_new

[patch 1] Xen core patch : ptep_establish_new

[Ian Pratt]

This patch adds 'ptep_establish_new', in keeping with the
existing 'ptep_establish', but for use where a mapping is being
established where there was previously none present. This
function is useful (rather than just using set_pte) because
having the virtual address available enables a very important
optimisation for arch-xen. We introduce
HAVE_ARCH_PTEP_ESTABLISH_NEW and define a generic implementation
in asm-generic/pgtable.h, following the pattern of the existing
ptep_establish.

Signed-off-by: ian.pratt@cl.cam.ac.uk

---

diff -Nurp pristine-linux-2.6.9/include/asm-generic/pgtable.h tmp-linux-2.6.9-xen.patch/include/asm-generic/pgtable.h
--- pristine-linux-2.6.9/include/asm-generic/pgtable.h	2004-10-18 22:53:46.000000000 +0100
+++ tmp-linux-2.6.9-xen.patch/include/asm-generic/pgtable.h	2004-11-04 23:27:24.000000000 +0000
@@ -42,6 +42,13 @@ do {				  					  \
 } while (0)
 #endif
 
+#ifndef __HAVE_ARCH_PTEP_ESTABLISH_NEW
+/*
+ * Establish a mapping where none previously existed
+ */
+#define ptep_establish_new(__vma, __address, __ptep, __entry)		\
+do {									\
+	set_pte(__ptep, __entry);					\
+} while (0)
+#endif
+
 #ifndef __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
 static inline int ptep_test_and_clear_young(pte_t *ptep)
 {
diff -Nurp pristine-linux-2.6.9/mm/memory.c tmp-linux-2.6.9-xen.patch/mm/memory.c
--- pristine-linux-2.6.9/mm/memory.c	2004-10-18 22:54:07.000000000 +0100
+++ tmp-linux-2.6.9-xen.patch/mm/memory.c	2004-11-04 23:27:25.000000000 +0000
@@ -1452,7 +1452,7 @@ do_anonymous_page(struct mm_struct *mm, 
 		page_add_anon_rmap(page, vma, addr);
 	}
 
-	set_pte(page_table, entry);
+	ptep_establish_new(vma, addr, page_table, entry);
 	pte_unmap(page_table);
 
 	/* No need to invalidate - it was non-present before */
@@ -1557,7 +1557,7 @@ retry:
 		entry = mk_pte(new_page, vma->vm_page_prot);
 		if (write_access)
 			entry = maybe_mkwrite(pte_mkdirty(entry), vma);
-		set_pte(page_table, entry);
+		ptep_establish_new(vma, address, page_table, entry);
 		if (anon) {
 			lru_cache_add_active(new_page);
 			page_add_anon_rmap(new_page, vma, address);

Re: [patch 1] Xen core patch : ptep_establish_new

[Andrew Morton]

Ian Pratt <Ian.Pratt@cl.cam.ac.uk> wrote:
>
> diff -Nurp pristine-linux-2.6.9/include/asm-generic/pgtable.h tmp-linux-2.6.9-xen.patch/include/asm-generic/pgtable.h
>  --- pristine-linux-2.6.9/include/asm-generic/pgtable.h	2004-10-18 22:53:46.000000000 +0100
>  +++ tmp-linux-2.6.9-xen.patch/include/asm-generic/pgtable.h	2004-11-04 23:27:24.000000000 +0000
>  @@ -42,6 +42,13 @@ do {				  					  \
>   } while (0)
>   #endif

This patch is mangled and doesn't apply.

Re: [patch 1] Xen core patch : ptep_establish_new

[Christoph Hellwig]

On Wed, Nov 17, 2004 at 11:46:50PM +0000, Ian Pratt wrote:
> 
> This patch adds 'ptep_establish_new', in keeping with the
> existing 'ptep_establish', but for use where a mapping is being
> established where there was previously none present. This
> function is useful (rather than just using set_pte) because
> having the virtual address available enables a very important
> optimisation for arch-xen. We introduce
> HAVE_ARCH_PTEP_ESTABLISH_NEW and define a generic implementation
> in asm-generic/pgtable.h, following the pattern of the existing
> ptep_establish.

What would be the problem of always passing the virtual address to
ptep_establish?  We already have a rather twisted maze of pte manipulation
macros.

Re: [patch 1] Xen core patch : ptep_establish_new

[Ian Pratt]

> On Wed, Nov 17, 2004 at 11:46:50PM +0000, Ian Pratt wrote:
> > 
> > This patch adds 'ptep_establish_new', in keeping with the
> > existing 'ptep_establish', but for use where a mapping is being
> > established where there was previously none present. This
> > function is useful (rather than just using set_pte) because
> > having the virtual address available enables a very important
> > optimisation for arch-xen. We introduce
> > HAVE_ARCH_PTEP_ESTABLISH_NEW and define a generic implementation
> > in asm-generic/pgtable.h, following the pattern of the existing
> > ptep_establish.
> 
> What would be the problem of always passing the virtual address to
> ptep_establish?  We already have a rather twisted maze of pte manipulation
> macros.

ptep_establish already takes a virtual address. Perhaps you mean
'set_pte'? That would work, but is a much bigger change that
would impact all architectures. I think introducing
ptep_establish_new is cleaner.

Ian

Re: [patch 1] Xen core patch : ptep_establish_new

[Keir Fraser]

> > On Wed, Nov 17, 2004 at 11:46:50PM +0000, Ian Pratt wrote:
> > > 
> > > This patch adds 'ptep_establish_new', in keeping with the
> > > existing 'ptep_establish', but for use where a mapping is being
> > > established where there was previously none present. This
> > > function is useful (rather than just using set_pte) because
> > > having the virtual address available enables a very important
> > > optimisation for arch-xen. We introduce
> > > HAVE_ARCH_PTEP_ESTABLISH_NEW and define a generic implementation
> > > in asm-generic/pgtable.h, following the pattern of the existing
> > > ptep_establish.
> > 
> > What would be the problem of always passing the virtual address to
> > ptep_establish?  We already have a rather twisted maze of pte manipulation
> > macros.
> 
> ptep_establish already takes a virtual address. Perhaps you mean
> 'set_pte'? That would work, but is a much bigger change that
> would impact all architectures. I think introducing
> ptep_establish_new is cleaner.

Also, we want to know which PTE updates are to a virtual address
within the *current* address space. Just adding a VA to every set_pte
use wouldn't tell us that (without yet another parameter ;-).

 -- Keir

Re: [patch 1] Xen core patch : ptep_establish_new

[Paul Mackerras]

Christoph Hellwig writes:

> On Wed, Nov 17, 2004 at 11:46:50PM +0000, Ian Pratt wrote:
> > 
> > This patch adds 'ptep_establish_new', in keeping with the
> > existing 'ptep_establish', but for use where a mapping is being
> > established where there was previously none present. This
> > function is useful (rather than just using set_pte) because
> > having the virtual address available enables a very important
> > optimisation for arch-xen. We introduce
> > HAVE_ARCH_PTEP_ESTABLISH_NEW and define a generic implementation
> > in asm-generic/pgtable.h, following the pattern of the existing
> > ptep_establish.
> 
> What would be the problem of always passing the virtual address to
> ptep_establish?  We already have a rather twisted maze of pte manipulation
> macros.

Dave Miller had a patch that passes the mm and virtual address to
set_pte.  That helps on sparc64 and ppc/ppc64, and it sounds like it
would help here too.

Paul.