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: [email protected]
---
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);
Ian Pratt <[email protected]> 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.
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.
> 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
> > 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
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.