Hi Wu, On Tue, Apr 26, 2011 at 3:34 PM, Wu Fengguang <fengguang.wu@xxxxxxxxx> wrote: > On Tue, Apr 26, 2011 at 02:29:15PM +0800, Dave Young wrote: >> On Tue, Apr 26, 2011 at 2:25 PM, Wu Fengguang <fengguang.wu@xxxxxxxxx> wrote: >> > On Tue, Apr 26, 2011 at 02:07:17PM +0800, Dave Young wrote: >> >> On Tue, Apr 26, 2011 at 2:05 PM, Dave Young <hidave.darkstar@xxxxxxxxx> wrote: >> >> > On Tue, Apr 26, 2011 at 1:55 PM, Wu Fengguang <fengguang.wu@xxxxxxxxx> wrote: >> >> >> On Tue, Apr 26, 2011 at 01:49:25PM +0800, Dave Young wrote: >> >> >>> Hi, >> >> >>> >> >> >>> When memory pressure is high, readahead could cause oom killing. >> >> >>> IMHO we should stop readaheading under such circumstancesãIf it's true >> >> >>> how to fix it? >> >> >> >> >> >> Good question. Before OOM there will be readahead thrashings, which >> >> >> can be addressed by this patch: >> >> >> >> >> >> http://lkml.org/lkml/2010/2/2/229 >> >> > >> >> > Hi, I'm not clear about the patch, could be regard as below cases? >> >> > 1) readahead alloc fail due to low memory such as other large allocation >> >> >> >> For example vm balloon allocate lots of memory, then readahead could >> >> fail immediately and then oom >> > >> > If true, that would be the problem of vm balloon. It's not good to >> > consume lots of memory all of a sudden, which will likely impact lots >> > of kernel subsystems. >> > >> > btw readahead page allocations are completely optional. They are OK to >> > fail and in theory shall not trigger OOM on themselves. We may >> > consider passing __GFP_NORETRY for readahead page allocations. >> >> Good idea, care to submit a patch? > > Here it is :) > > Thanks, > Fengguang > --- > readahead: readahead page allocations is OK to fail > > Pass __GFP_NORETRY 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> > Signed-off-by: Wu Fengguang <fengguang.wu@xxxxxxxxx> > --- > Âinclude/linux/pagemap.h |  Â5 +++++ > Âmm/readahead.c     Â|  Â2 +- > Â2 files changed, 6 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 14:29:31.000000000 +0800 > @@ -219,6 +219,11 @@ static inline struct page *page_cache_al >    Âreturn __page_cache_alloc(mapping_gfp_mask(x)|__GFP_COLD); > Â} > > +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? -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href