RE: [RFC][PATCH] avoid swapping out with swappiness==0

[Satoru Moriya]

On 04/20/2012 08:21 PM, Satoru Moriya wrote:
> On 04/04/2012 01:38 PM, KOSAKI Motohiro wrote:
>> (4/3/12 4:25 AM), Jerome Marchand wrote:
>>> On 04/02/2012 07:10 PM, KOSAKI Motohiro wrote:
>>>> 2012/3/30 Satoru Moriya<satoru.moriya@xxxxxxx>:
>>>>> So the kernel reclaims pages like following.
>>>>>
>>>>> nr_free + nr_filebacked>= watermark_high: reclaim only filebacked pages
>>>>> nr_free + nr_filebacked<   watermark_high: reclaim only anonymous pages
>>>>
>>>> How?
>>>
>>> get_scan_count() checks that case explicitly:
>>>
>>>     if (global_reclaim(sc)) {
>>>         free  = zone_page_state(mz->zone, NR_FREE_PAGES);
>>>         /* If we have very few page cache pages,
>>>            force-scan anon pages. */
>>>         if (unlikely(file + free<= high_wmark_pages(mz->zone))) {
>>>             fraction[0] = 1;
>>>             fraction[1] = 0;
>>>             denominator = 1;
>>>             goto out;
>>>         }
>>>     }
>>
>> Eek. This is silly. Nowaday many people enabled THP and it increase zone watermark.
>> so, high watermask is not good threshold anymore.
> 
> Ah yes, it is not so small now.
> On 4GB server, without THP min_free_kbytes is 8113 but with THP it is 
> 67584.
> 
> How about using low watermark or min watermark?
> Are they still big?
> 
> ...or should we use other value? 

What do you think of the idea above?

By the way, I'd like to discuss this topic in other thread
because discussion about optimal threshold where the kernel
changes its reclaim policy does not affect only swappiness==0
case but also all other settings. 

So, I propose that we start with applying this patch first
and then discuss/improve the threshold.

The patch may not be perfect but, at least, we can improve
the kernel behavior in the enough filebacked memory case
with this patch. I believe it's better than nothing.

Regards,
Satoru
--
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/