linux-kernel - Re: Control page reclaim granularity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 Mar 2012 09:28:06 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	Minchan Kim <minchan@...nel.org>, linux-mm <linux-mm@...ck.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Konstantin Khlebnikov <khlebnikov@...nvz.org>, riel@...hat.com,
	kosaki.motohiro@...fujitsu.com
Subject: Re: 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
--
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/