From: Zheng Liu <gnehzuil.liu@gmail.com>
To: linux-mm@kvack.org
Subject: Fine granularity page reclaim
Date: Fri, 17 Feb 2012 17:22:05 +0800 [thread overview]
Message-ID: <20120217092205.GA9462@gmail.com> (raw)
Hi all,
Currently, we encounter a problem about page reclaim. In our product system,
there is a lot of applictions that manipulate a number of files. In these
files, they can be divided into two categories. One is index file, another is
block file. The number of index files is about 15,000, and the number of
block files is about 23,000 in a 2TB disk. The application accesses index
file using mmap(2), and read/write block file using pread(2)/pwrite(2). We hope
to hold index file in memory as much as possible, and it works well in Redhat
2.6.18-164. It is about 60-70% of index files that can be hold in memory.
However, it doesn't work well in Redhat 2.6.32-133. I know in 2.6.18 that the
linux uses an active list and an inactive list to handle page reclaim, and in
2.6.32 that they are divided into anonymous list and file list. So I am
curious about why most of index files can be hold in 2.6.18? The index file
should be replaced because mmap doesn't impact the lru list.
BTW, I have some problems that need to be discussed.
1. I want to let index and block files are separately reclaimed. Is there any
ways to satisify me in current upstream?
2. Maybe we can provide a mechansim to let different files to be mapped into
differnet nodes. we can provide a ioctl(2) to tell kernel that this file should
be mapped into a specific node id. A nid member is added into addpress_space
struct. When alloc_page is called, the page can be allocated from that specific
node id.
3. Currently the page can be reclaimed according to pid in memcg. But it is too
coarse. I don't know whether memcg could provide a fine granularity page
reclaim mechansim. For example, the page is reclaimed according to inode number.
I don't subscribe this mailing list, So please Cc me. Thank you.
Regards,
Zheng
--
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 reply other threads:[~2012-02-17 9:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-17 9:22 Zheng Liu [this message]
2012-02-17 20:20 ` Fine granularity page reclaim Konstantin Khlebnikov
2012-02-20 6:20 ` Zheng Liu
2012-02-20 7:09 ` Konstantin Khlebnikov
2012-03-07 17:45 ` Zheng Liu
2012-03-07 20:33 ` Konstantin Khlebnikov
2012-03-08 2:54 ` Zheng Liu
2012-04-07 0:18 ` Ying Han
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=20120217092205.GA9462@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=linux-mm@kvack.org \
/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).