[patch 20/39] remap_file_pages protection support: optimize install_file_pte for MAP_POPULATE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Paolo 'Blaisorblade' Giarrusso <[email protected]>

Add an optimization to install_file_pte: if the VMA is uniform, and the PTE
was null, it will be installed correctly if needed at fault time - we avoid
thus touching the page tables, but we must still do the walk...

I'd like to avoid doing the walk altogether, when detecting that the VMA is
uniform.

I'm wondering why should the PTE have a wrong value? It could be a pte_file
PTE installed by a previous MAP_POPULATE or remap_file_pages call with
MAP_NONBLOCK, but that would either have been zapped (if we're handling
MAP_POPULATE) or it would be correct (if called by remap_file_pages, which is
unlikely since we're in a uniform VMA).

The protections must be correct, or we'd detect it by seeing VM_NONUNIFORM,
and the offset too, otherwise we'd see VM_NONLINEAR.

Thus it's just used for MAP_POPULATE|MAP_NONBLOCK.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
---

 linux-2.6.git-paolo/mm/fremap.c |    9 +++++++++
 1 files changed, 9 insertions(+)

diff -puN mm/fremap.c~rfp-linear-optim-v2 mm/fremap.c
--- linux-2.6.git/mm/fremap.c~rfp-linear-optim-v2	2005-08-11 22:46:58.000000000 +0200
+++ linux-2.6.git-paolo/mm/fremap.c	2005-08-11 22:57:49.000000000 +0200
@@ -121,6 +121,9 @@ int install_file_pte(struct mm_struct *m
 	pud_t *pud;
 	pgd_t *pgd;
 	pte_t pte_val;
+	int uniform = !(vma->vm_flags & (VM_NONUNIFORM | VM_NONLINEAR));
+
+ 	BUG_ON(!uniform && !(vma->vm_flags & VM_SHARED));
 
 	pgd = pgd_offset(mm, addr);
 	spin_lock(&mm->page_table_lock);
@@ -136,6 +139,12 @@ int install_file_pte(struct mm_struct *m
 	pte = pte_alloc_map(mm, pmd, addr);
 	if (!pte)
 		goto err_unlock;
+	/*
+	 * Skip uniform non-existent ptes:
+	 */
+	err = 0;
+	if (uniform && pte_none(*pte))
+		goto err_unlock;
 
 	zap_pte(mm, vma, addr, pte);
 
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux