Re: [patch] do_no_pfn()

[Andrew Morton <akpm@osdl.org>]

On 20 Sep 2006 03:25:25 -0400
Jes Sorensen <jes@sgi.com> wrote:

> Implement do_no_pfn() for handling mapping of memory without a struct
> page backing it. This avoids creating fake page table entries for
> regions which are not backed by real memory.
> 
> This feature is used by the MSPEC driver and other users, where it is
> highly undesirable to have a struct page sitting behind the page
> (for instance if the page is accessed in cached mode via the struct
> page in parallel to the the driver accessing it uncached, which can
> result in data corruption on some architectures, such as ia64).
> 
> This version uses specific NOPFN_{SIGBUS,OOM} return values, rather
> than expect all negative pfn values would be an error. It also bugs on
> cow mappings as this would not work with the VM.


How does this followup look?


We don't want the rarely-used do_no_pfn() to get inlined in the oft-used
handle_pte_fault(), using up icache.  Mark it noinline and unlikely.


--- a/mm/memory.c~do_no_pfn-tweaks
+++ a/mm/memory.c
@@ -2276,8 +2276,10 @@ oom:
  *
  * It is expected that the ->nopfn handler always returns the same pfn
  * for a given virtual mapping.
+ *
+ * Mark this `noinline' to prevent it from bloating the main pagefault code.
  */
-static int do_no_pfn(struct mm_struct *mm, struct vm_area_struct *vma,
+static noinline int do_no_pfn(struct mm_struct *mm, struct vm_area_struct *vma,
 		     unsigned long address, pte_t *page_table, pmd_t *pmd,
 		     int write_access)
 {
@@ -2376,7 +2378,7 @@ static inline int handle_pte_fault(struc
 					return do_no_page(mm, vma, address,
 							  pte, pmd,
 							  write_access);
-				if (vma->vm_ops->nopfn)
+				if (unlikely(vma->vm_ops->nopfn))
 					return do_no_pfn(mm, vma, address, pte,
 							 pmd, write_access);
 			}
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/