Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761942Ab1EOWko (ORCPT ); Sun, 15 May 2011 18:40:44 -0400 Received: from mail-qw0-f46.google.com ([209.85.216.46]:40874 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759876Ab1EOWkn convert rfc822-to-8bit (ORCPT ); Sun, 15 May 2011 18:40:43 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vVVHFfaLFOOSW2nLnRBAYWD1lY2AM3bVnzgbbc83FB0ADW4DcjRaNqSbRGfhHXtpUD 4wFMznLGOmycHOr+wm86yLkF+bV8LDda0tllUoPyuNNU8TDqxwD6oe4fcrrl26g//Awv kzGsoy2IhICpBdAXOXzkZzfyhsyZMpLqGQyoY= 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> Date: Mon, 16 May 2011 07:40:42 +0900 Message-ID: Subject: Re: Kernel falls apart under light memory pressure (i.e. linking vmlinux) From: Minchan Kim To: Wu Fengguang Cc: Andi Kleen , "linux-mm@kvack.org" , Andrew Lutomirski , LKML Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2176 Lines: 58 On Mon, May 16, 2011 at 12: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. 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. :) > > - 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. My patch and shrinking RA window helps this case. -- Kind regards, Minchan Kim -- 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/