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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>