From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by rv-out-0708.google.com with SMTP id f25so11216335rvb.26 for ; Tue, 24 Jun 2008 23:56:55 -0700 (PDT) Message-ID: <28c262360806242356n3f7e02abwfee1f6acf0fd2c61@mail.gmail.com> Date: Wed, 25 Jun 2008 15:56:54 +0900 From: "MinChan Kim" Subject: Re: [RFC][PATCH] prevent incorrect oom under split_lru In-Reply-To: <20080625150141.D845.KOSAKI.MOTOHIRO@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080624092824.4f0440ca@bree.surriel.com> <28c262360806242259k3ac308c4n7cee29b72456e95b@mail.gmail.com> <20080625150141.D845.KOSAKI.MOTOHIRO@jp.fujitsu.com> Sender: owner-linux-mm@kvack.org Return-Path: To: KOSAKI Motohiro Cc: Rik van Riel , linux-mm , LKML , Lee Schermerhorn , akpm@linux-foundation.org, Takenori Nagano List-ID: On Wed, Jun 25, 2008 at 3:08 PM, KOSAKI Motohiro wrote: > Hi Kim-san, > >> >> 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. > > No problem. > > priority==0 indicate emergency. > it doesn't happend on typical workload. > I see :) But if such emergency happen in embedded system, application can't be executed for some time. I am not sure how long time it take. But In some application, schedule period is very important than memory reclaim latency. Now, In your patch, when such emergency happen, it continue to reclaim page until it will scan entire page of lru list. It >> 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. > > I think this is off-topic. > > but Yes. > both my page reclaim throttle and nagano-san's patch provide > reclaim cut off mechanism. > > > and more off-topic, > nagano-san's patch improve only priority==12. > So, typical embedded doesn't improve so big because > embedded system does't have so large memory. > > > > -- Kinds regards, MinChan Kim -- 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