Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754716AbYFYF7i (ORCPT ); Wed, 25 Jun 2008 01:59:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752140AbYFYF72 (ORCPT ); Wed, 25 Jun 2008 01:59:28 -0400 Received: from an-out-0708.google.com ([209.85.132.246]:65031 "EHLO an-out-0708.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750923AbYFYF71 (ORCPT ); Wed, 25 Jun 2008 01:59:27 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rPkEajPSpklmcmJHHfeDv7RA45YJrQy9wiHRXVYbYbfRP4oV4waAKRkUyPaSliowTP 7JjAoYBMCucDxHY4E8OpUjnzUWUGUTdjhFYejpIfwXiAmFmlvwavEIbjDzD5Bxz6WyLz RZa0+KsYTwmr+HVFwp1r7k0xB+1hdn1UgkNGo= Message-ID: <28c262360806242259k3ac308c4n7cee29b72456e95b@mail.gmail.com> Date: Wed, 25 Jun 2008 14:59:26 +0900 From: "MinChan Kim" To: "Rik van Riel" , "KOSAKI Motohiro" Subject: Re: [RFC][PATCH] prevent incorrect oom under split_lru Cc: linux-mm , LKML , "Lee Schermerhorn" , akpm@linux-foundation.org, "Takenori Nagano" In-Reply-To: <20080624092824.4f0440ca@bree.surriel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080624171816.D835.KOSAKI.MOTOHIRO@jp.fujitsu.com> <20080624092824.4f0440ca@bree.surriel.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2590 Lines: 75 On Tue, Jun 24, 2008 at 10:28 PM, Rik van Riel wrote: > On Tue, 24 Jun 2008 17:31:54 +0900 > KOSAKI Motohiro wrote: > >> if zone->recent_scanned parameter become inbalanceing anon and file, >> OOM killer can happened although swappable page exist. >> >> So, if priority==0, We should try to reclaim all page for prevent OOM. > > You are absolutely right. Good catch. I have a concern about application latency. If lru list have many pages, it take a very long time to scan pages. More system have many ram, More many time to scan pages. Of course I know this is trade-off between memory efficiency VS latency. But In embedded, some application think latency is more important thing than memory efficiency. We need some mechanism to cut off scanning time. I think Takenori Nagano's "memory reclaim more efficiently patch" is proper to reduce application latency in this case If we modify some code. What do you think about it ? >> Signed-off-by: KOSAKI Motohiro > > Acked-by: Rik van Riel > >> --- >> mm/vmscan.c | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> Index: b/mm/vmscan.c >> =================================================================== >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -1464,8 +1464,10 @@ static unsigned long shrink_zone(int pri >> * kernel will slowly sift through each list. >> */ >> scan = zone_page_state(zone, NR_LRU_BASE + l); >> - scan >>= priority; >> - scan = (scan * percent[file]) / 100; >> + if (priority) { >> + scan >>= priority; >> + scan = (scan * percent[file]) / 100; >> + } >> zone->lru[l].nr_scan += scan + 1; >> nr[l] = zone->lru[l].nr_scan; >> if (nr[l] >= sc->swap_cluster_max) >> > > > -- > All rights reversed. > > -- > 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/ . > Don't email: email@kvack.org > -- Kinds 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/