On Mon, May 16, 2011 at 07:40:42AM +0900, Minchan Kim wrote: > On Mon, May 16, 2011 at 12:27 AM, Wu Fengguang <fengguang.wu@xxxxxxxxx> wrote: > > On Sun, May 15, 2011 at 09:37:58AM +0800, Minchan Kim wrote: > >> On Sun, May 15, 2011 at 2:43 AM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: > >> > Copying back linux-mm. > >> > > >> >> Recently, we added following patch. > >> >> https://lkml.org/lkml/2011/4/26/129 > >> >> If it's a culprit, the patch should solve the problem. > >> > > >> > It would be probably better to not do the allocations at all under > >> > memory pressure. ÂEven if the RA allocation doesn't go into reclaim > >> > >> Fair enough. > >> I think we can do it easily now. > >> If page_cache_alloc_readahead(ie, GFP_NORETRY) is fail, we can adjust > >> RA window size or turn off a while. The point is that we can use the > >> fail of __do_page_cache_readahead as sign of memory pressure. > >> Wu, What do you think? > > > > No, disabling readahead can hardly help. > > I don't mean we have to disable RA. > As I said, the point is that we can use __GFP_NORETRY alloc fail as > _sign_ of memory pressure. I see. > > > > The sequential readahead memory consumption can be estimated by > > > > Â Â Â Â Â Â Â Â2 * (number of concurrent read streams) * (readahead window size) > > > > And you can double that when there are two level of readaheads. > > > > Since there are hardly any concurrent read streams in Andy's case, > > the readahead memory consumption will be ignorable. > > > > Typically readahead thrashing will happen long before excessive > > GFP_NORETRY failures, so the reasonable solutions are to > > If it is, RA thrashing could be better sign than failure of __GFP_NORETRY. > If we can do it easily, I don't object it. :) Yeah, the RA thrashing is much better sign because it not only happens long before normal __GFP_NORETRY failures, but also offers hint on how tight memory pressure it is. We can then shrink the readahead window adaptively to the available page cache memory :) > > > > - shrink readahead window on readahead thrashing > > Â(current readahead heuristic can somehow do this, and I have patches > > Âto further improve it) > > Good to hear. :) > I don't want RA steals high order page in memory pressure. More often than not it won't be RA's fault :) When you see RA page allocations stealing high order pages, it may actually be reflecting some more general order-0 steal order-N problem.. > My patch and shrinking RA window helps this case. Thanks, Fengguang -- 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=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>