And the second fix (cleanup patch will follow)
Pagecache: find_or_create_page does not spread memory.
The find_or_create function calls alloc_page with the gfp_mask passed to it
which is derived from the mappings gfp mask. So the allocation flags are right
(assuming my bugfix to fs/buffer.c is applied).
However, we call a alloc_page instead of page_cache_alloc in
find_or_create_page.
This means that the page cache allocation will not obey cpuset memory spreading.
We really need to call __page_cache_alloc there.
Also stick a comment in there explaining how the allocation mask passed to
find_or_create_page needs to be handled.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/filemap.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
Index: linux-2.6.21-rc7/mm/filemap.c
===================================================================
--- linux-2.6.21-rc7.orig/mm/filemap.c 2007-04-23 15:37:27.000000000 -0700
+++ linux-2.6.21-rc7/mm/filemap.c 2007-04-23 15:38:09.000000000 -0700
@@ -648,7 +648,8 @@ EXPORT_SYMBOL(find_lock_page);
* find_or_create_page - locate or add a pagecache page
* @mapping: the page's address_space
* @index: the page's index into the mapping
- * @gfp_mask: page allocation mode
+ * @gfp_mask: page allocation mode. This must be derived from the
+ * allocation flags of the mapping!
*
* Locates a page in the pagecache. If the page is not present, a new page
* is allocated using @gfp_mask and is added to the pagecache and to the VM's
@@ -670,7 +671,8 @@ repeat:
page = find_lock_page(mapping, index);
if (!page) {
if (!cached_page) {
- cached_page = alloc_page(gfp_mask);
+ cached_page =
+ __page_cache_alloc(gfp_mask);
if (!cached_page)
return NULL;
}
-
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/
