lkml.org 
[lkml]   [2007]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: Pagecache: find_or_create_page does not call a proper page allocator function
On Tue, 24 Apr 2007, Andrew Morton wrote:
>
> From my reading it would be pretty simple to teach unmap_and_move()
> to pass mapping_gfp_mask(page_mapping(page)) down into
> (*get_new_page)() to get the correct type of page.

Or even simpler, since they're already passed the source page,
just get it from that. However, I'm much less able to test this
patch in a hurry: it looks plausible, builds and runs okay in my
non-NUMA testing; but whether it does what I intend it to do,
without causing unexpected side-effects, I don't know.

Whereas I did check the previous little vma_migratable() patch
did the right thing, and think it more suitable for lastminute
and -stable. This one would need real testing by real migrants
with real NUMA.

Or Christoph may prevail in persuading there's no such problem.


Is there a problem with page migration to HIGHMEM, if pages were
mapped from a GFP_USER block device? I failed to demonstrate any
problem, but here's a quick fix if needed.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
---

include/linux/migrate.h | 1 +
mm/mempolicy.c | 4 ++--
mm/migrate.c | 12 +++++++++---
mm/swap_state.c | 1 +
4 files changed, 13 insertions(+), 5 deletions(-)

--- 2.6.21-rc7/include/linux/migrate.h 2007-03-07 14:17:59.000000000 +0000
+++ linux/include/linux/migrate.h 2007-04-24 19:19:01.000000000 +0100
@@ -14,6 +14,7 @@ static inline int vma_migratable(struct
}

#ifdef CONFIG_MIGRATION
+extern gfp_t page_gfp_mask(struct page *page);
extern int isolate_lru_page(struct page *p, struct list_head *pagelist);
extern int putback_lru_pages(struct list_head *l);
extern int migrate_page(struct address_space *,
--- 2.6.21-rc7/mm/mempolicy.c 2007-03-07 14:18:01.000000000 +0000
+++ linux/mm/mempolicy.c 2007-04-24 19:19:01.000000000 +0100
@@ -594,7 +594,7 @@ static void migrate_page_add(struct page

static struct page *new_node_page(struct page *page, unsigned long node, int **x)
{
- return alloc_pages_node(node, GFP_HIGHUSER, 0);
+ return alloc_pages_node(node, page_gfp_mask(page), 0);
}

/*
@@ -710,7 +710,7 @@ static struct page *new_vma_page(struct
{
struct vm_area_struct *vma = (struct vm_area_struct *)private;

- return alloc_page_vma(GFP_HIGHUSER, vma, page_address_in_vma(page, vma));
+ return alloc_page_vma(page_gfp_mask(page), vma, page_address_in_vma(page, vma));
}
#else

--- 2.6.21-rc7/mm/migrate.c 2007-03-07 14:18:01.000000000 +0000
+++ linux/mm/migrate.c 2007-04-24 19:19:01.000000000 +0100
@@ -735,12 +735,18 @@ struct page_to_node {
int status;
};

-static struct page *new_page_node(struct page *p, unsigned long private,
+gfp_t page_gfp_mask(struct page *page)
+{
+ struct address_space *mapping = page_mapping(page);
+ return mapping? mapping_gfp_mask(mapping): GFP_HIGHUSER;
+}
+
+static struct page *new_page_node(struct page *page, unsigned long private,
int **result)
{
struct page_to_node *pm = (struct page_to_node *)private;

- while (pm->node != MAX_NUMNODES && pm->page != p)
+ while (pm->node != MAX_NUMNODES && pm->page != page)
pm++;

if (pm->node == MAX_NUMNODES)
@@ -748,7 +754,7 @@ static struct page *new_page_node(struct

*result = &pm->status;

- return alloc_pages_node(pm->node, GFP_HIGHUSER | GFP_THISNODE, 0);
+ return alloc_pages_node(pm->node, page_gfp_mask(page) | GFP_THISNODE, 0);
}

/*
--- 2.6.21-rc7/mm/swap_state.c 2006-09-20 04:42:06.000000000 +0100
+++ linux/mm/swap_state.c 2007-04-24 19:19:01.000000000 +0100
@@ -40,6 +40,7 @@ struct address_space swapper_space = {
.page_tree = RADIX_TREE_INIT(GFP_ATOMIC|__GFP_NOWARN),
.tree_lock = __RW_LOCK_UNLOCKED(swapper_space.tree_lock),
.a_ops = &swap_aops,
+ .flags = (__force unsigned long) GFP_HIGHUSER,
.i_mmap_nonlinear = LIST_HEAD_INIT(swapper_space.i_mmap_nonlinear),
.backing_dev_info = &swap_backing_dev_info,
};
-
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/
\
 
 \ /
  Last update: 2007-04-24 21:09    [W:0.236 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site