linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Nick Piggin <npiggin@suse.de>
Cc: akpm@linux-foundation.org, hugh@veritas.com,
	Linux Memory Management <linux-mm@kvack.org>
Subject: [RFC/PATCH] prepare_unmapped_area
Date: Tue, 06 Feb 2007 16:04:56 +1100	[thread overview]
Message-ID: <1170738296.2620.220.camel@localhost.localdomain> (raw)
In-Reply-To: <20070206044516.GA16647@wotan.suse.de>

Hi folks !

On Cell, I have, for performance reasons, a need to create special
mappings of SPEs that use a different page size as the system base page
size _and_ as the huge page size.

Due to the way the PowerPC memory management works, however, I can only
have one page size per "segment" of 256MB (or 1T) and thus after such a
mapping have been created in its own segment, I need to constraint
-other- vma's to stay out of that area.

This currently cannot be done with the existing arch hooks (because of
MAP_FIXED). However, the hugetlbfs code already has a hack in there to
do the exact same thing for huge pages. Thus, this patch moves that hack
into something that can be overriden by the architectures. This approach
was choosen as the less ugly of the uglies after discussing with Nick
Piggin. If somebody has a better idea, I'd love to hear it.

If it doesn't shoke anybody to death, I'd like to see that in -mm (and
possibly upstream, I don't know yet if my code using that will make
2.6.21 or not, but it would be nice if the list of "dependent" patches
wasn't 3 pages long anyway :-)

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---

Index: linux-cell/mm/mmap.c
===================================================================
--- linux-cell.orig/mm/mmap.c	2007-02-06 15:56:42.000000000 +1100
+++ linux-cell/mm/mmap.c	2007-02-06 15:59:23.000000000 +1100
@@ -1353,6 +1353,28 @@ void arch_unmap_area_topdown(struct mm_s
 		mm->free_area_cache = mm->mmap_base;
 }
 
+#ifndef HAVE_ARCH_PREPARE_UNMAPPED_AREA
+int arch_prepare_unmapped_area(struct file *file, unsigned long addr,
+			       unsigned long len, unsigned long pgoff,
+			       unsigned long flags)
+{
+	if (file && is_file_hugepages(file))  {
+		/*
+		 * Check if the given range is hugepage aligned, and
+		 * can be made suitable for hugepages.
+		 */
+		return prepare_hugepage_range(addr, len, pgoff);
+	} else {
+		/*
+		 * Ensure that a normal request is not falling in a
+		 * reserved hugepage range.  For some archs like IA-64,
+		 * there is a separate region for hugepages.
+		 */
+		return is_hugepage_only_range(current->mm, addr, len);
+	}
+}
+#endif /* HAVE_ARCH_PREPARE_UNMAPPED_AREA */
+
 unsigned long
 get_unmapped_area(struct file *file, unsigned long addr, unsigned long len,
 		unsigned long pgoff, unsigned long flags)
@@ -1374,20 +1396,7 @@ get_unmapped_area(struct file *file, uns
 		return -ENOMEM;
 	if (addr & ~PAGE_MASK)
 		return -EINVAL;
-	if (file && is_file_hugepages(file))  {
-		/*
-		 * Check if the given range is hugepage aligned, and
-		 * can be made suitable for hugepages.
-		 */
-		ret = prepare_hugepage_range(addr, len, pgoff);
-	} else {
-		/*
-		 * Ensure that a normal request is not falling in a
-		 * reserved hugepage range.  For some archs like IA-64,
-		 * there is a separate region for hugepages.
-		 */
-		ret = is_hugepage_only_range(current->mm, addr, len);
-	}
+	ret = arch_prepare_unmapped_area(file, addr, len, pgoff, flags);
 	if (ret)
 		return -EINVAL;
 	return addr;


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

       reply	other threads:[~2007-02-06  5:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200702060405.l1645R7G009668@shell0.pdx.osdl.net>
     [not found] ` <1170736938.2620.213.camel@localhost.localdomain>
     [not found]   ` <20070206044516.GA16647@wotan.suse.de>
2007-02-06  5:04     ` Benjamin Herrenschmidt [this message]
2007-02-06  5:31       ` [RFC/PATCH] prepare_unmapped_area Andrew Morton
2007-02-06  5:46         ` Benjamin Herrenschmidt
2007-02-06  5:58           ` Andrew Morton
2007-02-06  6:02             ` Benjamin Herrenschmidt
2007-02-06  6:08               ` Andrew Morton
2007-02-06  6:12             ` Nick Piggin
2007-02-06  6:37               ` Andrew Morton
2007-02-06  6:40                 ` Nick Piggin
2007-02-06  6:54                   ` Andrew Morton
2007-02-06  9:55       ` Christoph Hellwig
2007-02-06 10:07         ` Benjamin Herrenschmidt
2007-02-06 10:23           ` Christoph Hellwig
2007-02-06 15:56       ` Adam Litke
2007-02-06 20:12         ` Benjamin Herrenschmidt
2007-02-06 20:52           ` Adam Litke
2007-02-06 21:02             ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1170738296.2620.220.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=akpm@linux-foundation.org \
    --cc=hugh@veritas.com \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).