Re: Kernel falls apart under light memory pressure (i.e. linkingvmlinux)
From: Wu Fengguang
Date: Tue May 17 2011 - 01:52:15 EST
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.
> > 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.
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/