Re: mapped pagecache pages vs unmapped pages

From: Minchan Kim
Date: Mon Apr 09 2012 - 20:29:25 EST


2012-04-10 ìì 8:50, Alexey Ivanov ì ê:

> Did you consider making this ratio tunable, at least manually(i.e. via sysctl)?
> I suppose we are not the only ones with almost-whole-ram-mmaped workload.


Personally, I think it's not good approach.
It depends on kernel's internal implemenatation which would be changed
in future as we chagend it at 2.6.28.

In my opinion, kernel just should do best effort to keep active working
set except some critical pages which are code pages. If it's not active
working set but user want to keep them, we have to add new feature like
fadvise/madvise(WORKING_SET) to give the hint to kenrel. Although it
causes changing legacy programs, it doesn't copuled kernel's reclaim
algorithm and it's way to go, I think.

>
> 09.04.2012, 22:56, "Rik van Riel" <riel@xxxxxxxxxx>:
>> On 04/09/2012 01:11 PM, Alexey Ivanov wrote:
>>
>>> Thanks for the hint!
>>>
>>> Can anyone clarify the reason of not using zone->inactive_ratio in inactive_file_is_low_global()?
>>
>> New anonymous pages start out on the active anon list, and
>> are always referenced. If memory fills up, they may end
>> up getting moved to the inactive anon list; being referenced
>> while on the inactive anon list is enough to get them promoted
>> back to the active list.
>>
>> New file pages start out on the INACTIVE file list, and
>> start their lives not referenced at all. Due to readahead
>> extra reads, many file pages may never be referenced.
>>
>> Only file pages that are referenced twice make it onto
>> the active list.
>>
>> This means the inactive file list has to be large enough
>> for all the readahead buffers, and give pages enough time
>> on the list that frequently accessed ones can get accessed
>> twice and promoted.
>>
>> http://linux-mm.org/PageReplacementDesign
>>
>> --
>> All rights reversed
>



--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/