Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752418Ab1EQGAJ (ORCPT ); Tue, 17 May 2011 02:00:09 -0400 Received: from mga14.intel.com ([143.182.124.37]:56015 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752067Ab1EQGAE (ORCPT ); Tue, 17 May 2011 02:00:04 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.65,223,1304319600"; d="scan'208";a="437291494" Date: Tue, 17 May 2011 14:00:01 +0800 From: Wu Fengguang To: Andrew Lutomirski Cc: Minchan Kim , Andi Kleen , "linux-mm@kvack.org" , LKML Subject: Re: Kernel falls apart under light memory pressure (i.e. linking vmlinux) Message-ID: <20110517060001.GC24069@localhost> References: <20110512054631.GI6008@one.firstfloor.org> <20110514165346.GV6008@one.firstfloor.org> <20110514174333.GW6008@one.firstfloor.org> <20110515152747.GA25905@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3419 Lines: 90 On Sun, May 15, 2011 at 12:12:36PM -0400, Andrew Lutomirski wrote: > On Sun, May 15, 2011 at 11:27 AM, Wu Fengguang 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 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. > > > > 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 > > > > - shrink readahead window on readahead thrashing > >  (current readahead heuristic can somehow do this, and I have patches > >  to further improve it) > > > > - prevent abnormal GFP_NORETRY failures > >  (when there are many reclaimable pages) > > > > > > Andy's OOM memory dump (incorrect_oom_kill.txt.xz) shows that there are > > > > - 8MB   active+inactive file pages > > - 160MB active+inactive anon pages > > - 1GB   shmem pages > > - 1.4GB unevictable pages > > > > Hmm, why are there so many unevictable pages?  How 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.) Ah I didn't read your first email.. I'm now running ./test_mempressure.sh 1500 1400 1 with mem=2G and no swap, but cannot reproduce OOM. What's your kconfig? > If you want, I can try to generate a trace that isn't polluted with > the evil ramfs file. No, thanks. However it would be valuable if you can retry with this patch _alone_ (without the "if (need_resched()) return false;" change, as I don't see how it helps your case). @@ -2286,7 +2290,7 @@ static bool sleeping_prematurely(pg_data_t *pgdat, int order, long remaining, * must be balanced */ if (order) - return pgdat_balanced(pgdat, balanced, classzone_idx); + return !pgdat_balanced(pgdat, balanced, classzone_idx); else return !all_zones_ok; } Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/