linux-kernel - Re: mm: kswapd struggles reclaiming the pages on 64GB server

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAK-uSPqtiV5bbyimG+ZPwqOb3DByPNun22nJFtDQ66Z_t22-4w@mail.gmail.com>
Date:   Thu, 18 Aug 2016 18:43:34 +0100
From:   Andriy Tkachuk <andriy.tkachuk@...gate.com>
To:     Minchan Kim <minchan@...nel.org>
Cc:     linux-kernel@...r.kernel.org, Mel Gorman <mgorman@...e.de>
Subject: Re: mm: kswapd struggles reclaiming the pages on 64GB server

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@...nel.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.