From: Minchan Kim <minchan.kim@gmail.com>
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
Subject: Re: [PATCH 3/3] Provide control over unmapped pages (v4)
Date: Thu, 10 Feb 2011 14:33:00 +0900 [thread overview]
Message-ID: <AANLkTin4JM6phwy0wuV6fV-i-3UwP_GGmXh1vN=Wz2u=@mail.gmail.com> (raw)
In-Reply-To: <20110128111833.GD5054@balbir.in.ibm.com>
Sorry for late response.
On Fri, Jan 28, 2011 at 8:18 PM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> * MinChan Kim <minchan.kim@gmail.com> [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
next prev parent reply other threads:[~2011-02-10 5:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-25 5:10 [PATCH 1/2] Refactor zone_reclaim code (v4) Balbir Singh
2011-01-25 5:10 ` [PATCH 3/3] Provide control over unmapped pages (v4) Balbir Singh
2011-01-26 16:57 ` Christoph Lameter
2011-01-26 17:43 ` Balbir Singh
2011-01-26 23:12 ` Minchan Kim
2011-01-28 2:56 ` Balbir Singh
2011-01-28 5:44 ` Minchan Kim
2011-01-28 6:48 ` Balbir Singh
2011-01-28 7:24 ` Minchan Kim
2011-01-28 7:56 ` KAMEZAWA Hiroyuki
2011-01-28 8:19 ` Balbir Singh
2011-01-28 8:17 ` KAMEZAWA Hiroyuki
2011-01-28 12:02 ` Balbir Singh
2011-01-28 15:20 ` Christoph Lameter
2011-01-30 23:58 ` KAMEZAWA Hiroyuki
2011-01-31 4:37 ` Balbir Singh
2011-01-28 11:18 ` Balbir Singh
2011-02-10 5:33 ` Minchan Kim [this message]
2011-02-10 5:41 ` Minchan Kim
2011-02-13 17:33 ` Balbir Singh
2011-02-16 23:45 ` Minchan Kim
2011-01-25 5:15 ` [PATCH 1/2] Refactor zone_reclaim code (v4) Balbir Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTin4JM6phwy0wuV6fV-i-3UwP_GGmXh1vN=Wz2u=@mail.gmail.com' \
--to=minchan.kim@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=cl@linux.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@kernel.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox