From: Minchan Kim <minchan@kernel.org>
To: Rik van Riel <riel@redhat.com>
Cc: Minchan Kim <minchan@kernel.org>, linux-mm <linux-mm@kvack.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Konstantin Khlebnikov <khlebnikov@openvz.org>,
kosaki.motohiro@jp.fujitsu.com
Subject: Re: Control page reclaim granularity
Date: Tue, 13 Mar 2012 11:57:57 +0900 [thread overview]
Message-ID: <20120313025756.GC7125@barrios> (raw)
In-Reply-To: <4F5E0E5C.8040508@redhat.com>
On Mon, Mar 12, 2012 at 10:55:24AM -0400, Rik van Riel wrote:
> On 03/08/2012 04:35 AM, Minchan Kim wrote:
> >On Thu, Mar 08, 2012 at 03:34:13PM +0800, Zheng Liu wrote:
> >>Hi list,
> >>
> >>Recently we encounter a problem about page reclaim. I abstract it in here.
> >>The problem is that there are two different file types. One is small index
> >>file, and another is large data file. The index file is mmaped into memory,
> >>and application hope that they can be kept in memory and don't be reclaimed
> >>too frequently. The data file is manipulted by read/write, and they should
> >>be reclaimed more frequently than the index file.
>
> They should indeed be. The data pages should not get promoted
> to the active list unless they get referenced twice while on
> the inactive list.
>
> Mmaped pages, on the other hand, get promoted to the active
> list after just one reference.
As I look the code, mmaped page doesn't get promoted by one reference.
It will get promoted by second-round trip or touched by several mapping
when first round trip.
if (referenced_page || referenced_ptes > 1)
return PAGEREF_ACTIVATE;
>
> Also, as long as the inactive file list is larger than the
> active file list, we do not reclaim active file pages at
> all.
True.
>
> >I think it's a regression since 2.6.28.
> >Before we were trying to keep mapped pages in memory(See calc_reclaim_mapped).
> >But we removed that routine when we applied split lru page replacement.
> >Rik, KOSAKI. What's the rationale?
>
> One main reason is scalability. We have to treat pages
> in such a way that we do not have to search through
> gigabytes of memory to find a few eviction candidates
> to place on the inactive list - where they could get
> reused and stopped from eviction again.
Okay. Thanks, Rik.
Then, another question.
Why did we handle mmaped page specially at that time?
Just out of curiosity.
>
> --
> 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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-03-13 2:58 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-08 7:34 Control page reclaim granularity Zheng Liu
2012-03-08 8:39 ` Greg Thelen
2012-03-08 16:13 ` Zheng Liu
2012-03-08 16:32 ` Zhu Yanhai
2012-03-14 7:19 ` Greg Thelen
2012-03-08 9:35 ` Minchan Kim
2012-03-08 16:54 ` Zheng Liu
2012-03-12 0:28 ` Minchan Kim
2012-03-12 2:06 ` Fwd: " Zheng Liu
2012-03-12 5:19 ` Minchan Kim
2012-03-12 6:20 ` Konstantin Khlebnikov
2012-03-12 8:14 ` Zheng Liu
2012-03-12 13:42 ` Minchan Kim
2012-03-12 14:18 ` Konstantin Khlebnikov
2012-03-13 2:48 ` Minchan Kim
2012-03-13 4:37 ` Konstantin Khlebnikov
2012-03-13 5:00 ` Konstantin Khlebnikov
2012-03-13 6:30 ` Zheng Liu
2012-03-13 6:48 ` Zheng Liu
2012-03-13 7:21 ` Konstantin Khlebnikov
2012-03-13 7:43 ` Kautuk Consul
2012-03-13 7:47 ` Kautuk Consul
2012-03-13 8:05 ` Zheng Liu
2012-03-13 8:04 ` Kautuk Consul
2012-03-13 8:08 ` Kautuk Consul
2012-03-13 8:28 ` Zheng Liu
2012-03-13 8:36 ` Kautuk Consul
2012-03-13 9:03 ` Kautuk Consul
2012-03-12 15:15 ` Zheng Liu
2012-03-13 2:51 ` Minchan Kim
2012-03-12 14:55 ` Rik van Riel
2012-03-13 2:57 ` Minchan Kim [this message]
2012-03-13 14:57 ` Rik van Riel
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=20120313025756.GC7125@barrios \
--to=minchan@kernel.org \
--cc=khlebnikov@openvz.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).