Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754184Ab1BPXpP (ORCPT ); Wed, 16 Feb 2011 18:45:15 -0500 Received: from mail-iw0-f174.google.com ([209.85.214.174]:54530 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753159Ab1BPXpM (ORCPT ); Wed, 16 Feb 2011 18:45:12 -0500 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; b=nJL1qIRje4nrkb77RuP9Gj19fbhLdeee7wce3l6I0LyRLXdkwfrXublVcxHivwKbYA j2cIYyYdds9YHjyPm7oRHjJsHiNoWxRk/oZUWgR9kXUBhdb5qKyQEN616i42R895v4Uy B/9S9t1KdP5w1xCQ9eGKZ44oCP4c/lRnVw1o8= MIME-Version: 1.0 In-Reply-To: <20110213173336.GC23919@balbir.in.ibm.com> References: <20110125051003.13762.35120.stgit@localhost6.localdomain6> <20110125051015.13762.13429.stgit@localhost6.localdomain6> <20110128064851.GB5054@balbir.in.ibm.com> <20110128111833.GD5054@balbir.in.ibm.com> <20110213173336.GC23919@balbir.in.ibm.com> Date: Thu, 17 Feb 2011 08:45:11 +0900 Message-ID: Subject: Re: [PATCH 3/3] Provide control over unmapped pages (v4) From: Minchan Kim To: balbir@linux.vnet.ibm.com Cc: linux-mm@kvack.org, akpm@linux-foundation.org, npiggin@kernel.dk, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, kosaki.motohiro@jp.fujitsu.com, cl@linux.com, kamezawa.hiroyu@jp.fujitsu.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3581 Lines: 91 On Mon, Feb 14, 2011 at 2:33 AM, Balbir Singh wrote: > * MinChan Kim [2011-02-10 14:41:44]: > >> I don't know why the part of message is deleted only when I send you. >> Maybe it's gmail bug. >> >> I hope mail sending is successful in this turn. :) >> >> On Thu, Feb 10, 2011 at 2:33 PM, Minchan Kim wrote: >> > Sorry for late response. >> > >> > On Fri, Jan 28, 2011 at 8:18 PM, Balbir Singh wrote: >> >> * MinChan Kim [2011-01-28 16:24:19]: >> >> >> >>> > >> >>> > But the assumption for LRU order to change happens only if the page >> >>> > cannot be successfully freed, which means it is in some way active.. >> >>> > and needs to be moved no? >> >>> >> >>> 1. holded page by someone >> >>> 2. mapped pages >> >>> 3. active pages >> >>> >> >>> 1 is rare so it isn't the problem. >> >>> Of course, in case of 3, we have to activate it so no problem. >> >>> The problem is 2. >> >>> >> >> >> >> 2 is a problem, but due to the size aspects not a big one. Like you >> >> said even lumpy reclaim affects it. May be the reclaim code could >> >> honour may_unmap much earlier. >> > >> > Even if it is, it's a trade-off to get a big contiguous memory. I >> > don't want to add new mess. (In addition, lumpy is weak by compaction >> > as time goes by) >> > What I have in mind for preventing LRU ignore is that put the page >> > into original position instead of head of lru. Maybe it can help the >> > situation both lumpy and your case. But it's another story. >> > >> > How about the idea? >> > >> > I borrow the idea from CFLRU[1] >> > - PCFLRU(Page-Cache First LRU) >> > >> > When we allocates new page for page cache, we adds the page into LRU's tail. >> > When we map the page cache into page table, we rotate the page into LRU's head. >> > >> > So, inactive list's result is following as. >> > >> > M.P : mapped page >> > N.P : none-mapped page >> > >> > HEAD-M.P-M.P-M.P-M.P-N.P-N.P-N.P-N.P-N.P-TAIL >> > >> > Admin can set threshold window size which determines stop reclaiming >> > none-mapped page contiguously. >> > >> > I think it needs some tweak of page cache/page mapping functions but >> > we can use kswapd/direct reclaim without change. >> > >> > Also, it can change page reclaim policy totally but it's just what you >> > want, I think. >> > > > I am not sure how this would work, moreover the idea behind > min_unmapped_pages is to keep sufficient unmapped pages around for the > FS metadata and has been working with the existing code for zone > reclaim. What you propose is more drastic re-org of the LRU and I am > not sure I have the apetite for it. Yes. My suggestion can change LRU order totally but it can't meet your goal so it was a bad idea. Sorry for bothering you. I can add reviewed-by [1/3],[2/3], but still doubt [3/3]. LRU ordering problem as I mentioned is not only your problem but it's general problem these day(ex, more aggressive compaction/lumpy reclaim). So we may need general solution if it is real problem. Okay. I don't oppose your approach from now on until I can prove how much LRU-reordering makes bad effect. (But still I raise my eyebrow on implementation [3/3] but I don't oppose it until I suggest better approach) Thanks. -- 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/