From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by wf-out-1314.google.com with SMTP id 25so2142901wfc.11 for ; Wed, 23 Apr 2008 01:27:46 -0700 (PDT) Message-ID: Date: Wed, 23 Apr 2008 10:27:46 +0200 From: "=?ISO-8859-1?Q?Daniel_Sp=E5ng?=" Subject: Re: [PATCH 0/8][for -mm] mem_notify v6 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080402154910.9588.KOSAKI.MOTOHIRO@jp.fujitsu.com> <20080417182121.A8CA.KOSAKI.MOTOHIRO@jp.fujitsu.com> Sender: owner-linux-mm@kvack.org Return-Path: To: Tom May Cc: KOSAKI Motohiro , linux-mm@kvack.org, linux-kernel@vger.kernel.org List-ID: Hi Tom On 4/17/08, Tom May wrote: > > Here is the start and end of the output from the test program. At > each /dev/mem_notify notification Cached decreases, then eventually > Mapped decreases as well, which means the amount of time the program > has to free memory gets smaller and smaller. Finally the oom killer > is invoked because the program can't react quickly enough to free > memory, even though it can free at a faster rate than it can use > memory. My test is slow to free because it calls nanosleep, but this > is just a simulation of my actual program that has to perform garbage > collection before it can free memory. I have also seen this behaviour in my static tests with low mem notification on swapless systems. It is a problem with small programs (typically static test programs) where the text segment is only a few pages. I have not seen this behaviour in larger programs which use a larger working set. As long as the system working set is bigger than the amount of memory that needs to be allocated, between every notification reaction opportunity, it seems to be ok. /Daniel -- 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