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.10-rc2/include/asm-generic/pgtable.h tmp-linux-2.6.10-rc2-xen.patch/include/asm-generic/pgtable.h
--- pristine-linux-2.6.10-rc2/include/asm-generic/pgtable.h 2004-10-18 22:53:46.000000000 +0100
+++ tmp-linux-2.6.10-rc2-xen.patch/include/asm-generic/pgtable.h 2004-11-30 00:41:24.000000000 +0000
@@ -42,6 +42,16 @@ 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.10-rc2/mm/memory.c tmp-linux-2.6.10-rc2-xen.patch/mm/memory.c
--- pristine-linux-2.6.10-rc2/mm/memory.c 2004-11-30 01:20:25.000000000 +0000
+++ tmp-linux-2.6.10-rc2-xen.patch/mm/memory.c 2004-11-30 00:41:24.000000000 +0000
@@ -1472,7 +1472,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 */
@@ -1577,7 +1577,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);
On Tue, Nov 30, 2004 at 02:06:02AM +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.
this certainly is correct.
On Tue, 2004-11-30 at 02:06 +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.
I would rather move toward that patch that David Miller proposed a while
ago that makes sure the necessary infos (mm, address, ...) are always
passed to all PTE functions.
Is there also a need for ptep_establish and ptep_establish_new to be 2
different functions ?
Ben.
> On Tue, 2004-11-30 at 02:06 +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.
>
> I would rather move toward that patch that David Miller proposed a while
> ago that makes sure the necessary infos (mm, address, ...) are always
> passed to all PTE functions.
I'd appreciate a pointer to the patch.
It may still be of some use to distinguish between call sites
where it is likely that mm == current->mm to avoid adding a
futile test in all the others.
> Is there also a need for ptep_establish and ptep_establish_new to be 2
> different functions ?
They allow different TLB invalidation behaviour. I guess it could
be one function with an extra arg.
Ian
On Tue, 2004-11-30 at 23:05 +0000, Ian Pratt wrote:
> I'd appreciate a pointer to the patch.
Well, I was hoping that David would reply with one :) It wasn't ported
to all archs tho, but I did ppc & ppc64, and he did x86 & sparc iirc
> It may still be of some use to distinguish between call sites
> where it is likely that mm == current->mm to avoid adding a
> futile test in all the others.
Maybe ...
> > Is there also a need for ptep_establish and ptep_establish_new to be 2
> > different functions ?
>
> They allow different TLB invalidation behaviour. I guess it could
> be one function with an extra arg.
Not sure, my point is that we tend nowadays to have one abstraction per
call site, and I wonder if it's the right way to go ...
Ben.
On Wed, 01 Dec 2004 10:27:45 +1100
Benjamin Herrenschmidt <[email protected]> wrote:
> On Tue, 2004-11-30 at 23:05 +0000, Ian Pratt wrote:
>
> > I'd appreciate a pointer to the patch.
>
> Well, I was hoping that David would reply with one :) It wasn't ported
> to all archs tho, but I did ppc & ppc64, and he did x86 & sparc iirc
Attached, as a set of 3 diffs.
It's against an old tree so probably won't apply
cleanly.