Re: readahead and oom
From: Wu Fengguang
Date: Tue Apr 26 2011 - 05:20:47 EST
Minchan,
> > +static inline struct page *page_cache_alloc_cold_noretry(struct address_space *x)
> > +{
> > + Â Â Â return __page_cache_alloc(mapping_gfp_mask(x)|__GFP_COLD|__GFP_NORETRY);
>
> It makes sense to me but it could make a noise about page allocation
> failure. I think it's not desirable.
> How about adding __GFP_NOWARAN?
Yeah it makes sense. Here is the new version.
Thanks,
Fengguang
---
Subject: readahead: readahead page allocations is OK to fail
Date: Tue Apr 26 14:29:40 CST 2011
Pass __GFP_NORETRY|__GFP_NOWARN for readahead page allocations.
readahead page allocations are completely optional. They are OK to
fail and in particular shall not trigger OOM on themselves.
Reported-by: Dave Young <hidave.darkstar@xxxxxxxxx>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>
Signed-off-by: Wu Fengguang <fengguang.wu@xxxxxxxxx>
---
include/linux/pagemap.h | 6 ++++++
mm/readahead.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
--- linux-next.orig/include/linux/pagemap.h 2011-04-26 14:27:46.000000000 +0800
+++ linux-next/include/linux/pagemap.h 2011-04-26 17:17:13.000000000 +0800
@@ -219,6 +219,12 @@ static inline struct page *page_cache_al
return __page_cache_alloc(mapping_gfp_mask(x)|__GFP_COLD);
}
+static inline struct page *page_cache_alloc_readahead(struct address_space *x)
+{
+ return __page_cache_alloc(mapping_gfp_mask(x) |
+ __GFP_COLD | __GFP_NORETRY | __GFP_NOWARN);
+}
+
typedef int filler_t(void *, struct page *);
extern struct page * find_get_page(struct address_space *mapping,
--- linux-next.orig/mm/readahead.c 2011-04-26 14:27:02.000000000 +0800
+++ linux-next/mm/readahead.c 2011-04-26 17:17:25.000000000 +0800
@@ -180,7 +180,7 @@ __do_page_cache_readahead(struct address
if (page)
continue;
- page = page_cache_alloc_cold(mapping);
+ page = page_cache_alloc_readahead(mapping);
if (!page)
break;
page->index = page_offset;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/