From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1756320AbcHVSKb (ORCPT <rfc822;w@1wt.eu>);
        Mon, 22 Aug 2016 14:10:31 -0400
Received: from mx0b-00003501.pphosted.com ([67.231.152.68]:55455 "EHLO
        mx0a-000cda01.pphosted.com" rhost-flags-OK-OK-OK-FAIL)
        by vger.kernel.org with ESMTP id S1754777AbcHVSK3 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 22 Aug 2016 14:10:29 -0400
Authentication-Results: seagate.com;
        dkim=pass header.s="google" header.d=seagate.com
MIME-Version: 1.0
In-Reply-To: <20160818140513.GA2453@blaptop>
References: <CAK-uSPo9Nc-1HaURvwstOGYGuMEx4CXhPRv+cZevYLZX6URzYw@mail.gmail.com>
 <20160818140513.GA2453@blaptop>
From: Andriy Tkachuk <andriy.tkachuk@seagate.com>
Date: Mon, 22 Aug 2016 19:10:24 +0100
Message-ID: <CAK-uSPqbQ7jM=4oz=mzz4UkZKrFyhm2+X9552Cxz2Aj1Aj=aZQ@mail.gmail.com>
Subject: Re: mm: kswapd struggles reclaiming the pages on 64GB server
To: Minchan Kim <minchan@kernel.org>
Cc: linux-kernel@vger.kernel.org, Mel Gorman <mgorman@suse.de>
Content-Type: text/plain; charset=UTF-8
X-Proofpoint-PolicyRoute: Outbound
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-22_10:,,
 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=7
 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015
 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0
 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608220184
X-Proofpoint-Spam-Policy: Default Domain Policy
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Minchan,

That's an interesting idea. Although the counters contradicts the theory:

proc-vmstat-0616-160535.txt nr_active_file 44616
proc-vmstat-0616-160545.txt nr_active_file 43471
proc-vmstat-0616-160555.txt nr_active_file 44477
proc-vmstat-0616-160535.txt nr_inactive_file 55534
proc-vmstat-0616-160545.txt nr_inactive_file 35602
proc-vmstat-0616-160555.txt nr_inactive_file 36108
proc-vmstat-0616-160535.txt pgscan_kswapd_normal 111985367420
proc-vmstat-0616-160545.txt pgscan_kswapd_normal 111996845554
proc-vmstat-0616-160555.txt pgscan_kswapd_normal 112028276639
proc-vmstat-0616-160535.txt pgsteal_kswapd_normal 53817848
proc-vmstat-0616-160545.txt pgsteal_kswapd_normal 53818626
proc-vmstat-0616-160555.txt pgsteal_kswapd_normal 53818637

Anyway, I will give it a try if inactive_ratio=1 (which I'm currently
testing) won't help.

Thank you,
  Andriy

On Thu, Aug 18, 2016 at 3:05 PM, Minchan Kim <minchan@kernel.org> wrote:
>
> Currently, VM never reclaims anonymous pages if the number of inactive
> file LRU is greater than one of actice file LRU. Even, it makes
> user tune of vm.swappiness void.
>
> Could you rebuild your kernel? I want to see what happens if we
> remove below part from get_scan_count.
>
> http://lxr.free-electrons.com/source/mm/vmscan.c?v=3.10#L1728
>
> 1727         /*
> 1728          * There is enough inactive page cache, do not reclaim
> 1729          * anything from the anonymous working set right now.
> 1730          */
> 1731         if (!inactive_file_is_low(lruvec)) {
> 1732                 scan_balance = SCAN_FILE;
> 1733                 goto out;
> 1734         }
>
> Thanks.