From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with ESMTP id DA05B6B0012 for ; Sun, 15 May 2011 12:12:57 -0400 (EDT) Received: by pvc12 with SMTP id 12so2512206pvc.14 for ; Sun, 15 May 2011 09:12:56 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110515152747.GA25905@localhost> References: <20110512054631.GI6008@one.firstfloor.org> <20110514165346.GV6008@one.firstfloor.org> <20110514174333.GW6008@one.firstfloor.org> <20110515152747.GA25905@localhost> From: Andrew Lutomirski Date: Sun, 15 May 2011 12:12:36 -0400 Message-ID: Subject: Re: Kernel falls apart under light memory pressure (i.e. linking vmlinux) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Wu Fengguang Cc: Minchan Kim , Andi Kleen , "linux-mm@kvack.org" , LKML On Sun, May 15, 2011 at 11:27 AM, Wu Fengguang wro= te: > On Sun, May 15, 2011 at 09:37:58AM +0800, Minchan Kim wrote: >> On Sun, May 15, 2011 at 2:43 AM, Andi Kleen 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. =A0Even 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. > > The sequential readahead memory consumption can be estimated by > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02 * (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 > > - shrink readahead window on readahead thrashing > =A0(current readahead heuristic can somehow do this, and I have patches > =A0to further improve it) > > - prevent abnormal GFP_NORETRY failures > =A0(when there are many reclaimable pages) > > > Andy's OOM memory dump (incorrect_oom_kill.txt.xz) shows that there are > > - 8MB =A0 active+inactive file pages > - 160MB active+inactive anon pages > - 1GB =A0 shmem pages > - 1.4GB unevictable pages > > Hmm, why are there so many unevictable pages? =A0How come the shmem > pages become unevictable when there are plenty of swap space? That was probably because one of my testcases creates a 1.4GB file on ramfs. (I can provoke the problem without doing evil things like that, but the test script is rather reliable at killing my system and it works fine on my other machines.) If you want, I can try to generate a trace that isn't polluted with the evil ramfs file. --Andy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. 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: email@kvack.org