lkml.org 
[lkml]   [2012]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Control page reclaim granularity
On Fri, Mar 09, 2012 at 12:54:03AM +0800, Zheng Liu wrote:
> Hi Minchan,
>
> Sorry, I forgot to say that I don't subscribe linux-mm and linux-kernel
> mailing list. So please Cc me.
>
> IMHO, maybe we should re-think about how does user use mmap(2). I
> describe the cases I known in our product system. They can be
> categorized into two cases. One is mmaped all data files into memory
> and sometime it uses write(2) to append some data, and another uses
> mmap(2)/munmap(2) and read(2)/write(2) to manipulate the files. In the
> second case, the application wants to keep mmaped page into memory and
> let file pages to be reclaimed firstly. So, IMO, when application uses
> mmap(2) to manipulate files, it is possible to imply that it wants keep
> these mmaped pages into memory and do not be reclaimed. At least these
> pages do not be reclaimed early than file pages. I think that maybe we
> can recover that routine and provide a sysctl parameter to let the user
> to set this ratio between mmaped pages and file pages.

I am not convinced why we should handle mapped page specially.
Sometimem, someone may use mmap by reducing buffer copy compared to read system call.
So I think we can't make sure mmaped pages are always win.

My suggestion is that it would be better to declare by user explicitly.
I think we can implement it by madvise and fadvise's WILLNEED option.
Current implementation is just readahead if there isn't a page in memory but I think
we can promote from inactive to active if there is already a page in
memory.

It's more clear and it couldn't be affected by kernel page reclaim algorithm change
like this.

>
> Regards,
> Zheng


\
 
 \ /
  Last update: 2012-03-12 01:31    [W:0.122 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site