[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120308073412.GA6975@gmail.com>
Date: Thu, 8 Mar 2012 15:34:13 +0800
From: Zheng Liu <gnehzuil.liu@...il.com>
To: linux-mm <linux-mm@...ck.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Cc: Konstantin Khlebnikov <khlebnikov@...nvz.org>
Subject: Control page reclaim granularity
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.
As previously discussion [1], Konstantin suggest me to mmap index file with
PROT_EXEC flag. Meanwhile he provides a patch to set a flag in mm_flags to
increase the priority of mmaped file pages. However, these solutions are
not perfect. I review the related patches (8cab4754 and c909e993) and I
think that mmaped index file with PROT_EXEC flag is too tricky. From the
view of applicaton programmer, index file is a regular file that stores
some data. So they should be mmap with PROT_READ | PROT_WRITE rather than
with PROT_EXEC. As commit log said (8cab4754), the purpose of this patch
is to keep executable code in memory to improve the response of application.
In addition, Kongstantin's patch needs to adjust the application program.
So in some cases, we cannot touch the code of application, and this patch is
useless.
I have discussed with Kongstantin about this problem and we think maybe
kernel should provide some mechanism. For example, user can set memory
pressure priorities for vma or inode, or mmaped pages and file pages can be
reclaimed separately. If someone has thought about it, please let me know.
Any feedbacks are welcomed. Thank you.
Previously discussion:
1. http://marc.info/?l=linux-mm&m=132947026019538&w=2
Regards,
Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists