Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Date:   Mon, 9 Oct 2023 09:34:30 +0200
From:   Michal Hocko <mhocko@suse.com>
To:     "Huang, Ying" <ying.huang@intel.com>
Cc:     Jianlin Lv <iecedge@gmail.com>, tj@kernel.org,
        lizefan.x@bytedance.com, hannes@cmpxchg.org, corbet@lwn.net,
        roman.gushchin@linux.dev, shakeelb@google.com,
        muchun.song@linux.dev, akpm@linux-foundation.org,
        yosryahmed@google.com, willy@infradead.org, linmiaohe@huawei.com,
        wangkefeng.wang@huawei.com, laoar.shao@gmail.com,
        yuzhao@google.com, wuyun.abel@bytedance.com, david@redhat.com,
        peterx@redhat.com, vishal.moola@gmail.com, hughd@google.com,
        cgroups@vger.kernel.org, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org, jianlv@ebay.com
Subject: Re: [PATCH] memcg: add interface to force disable swap
Message-ID: <ZSOtBsigRV4RGNXn@dhcp22.suse.cz>
References: <20231007130905.78554-1-jianlv@ebay.com>
 <87mswtkj8x.fsf@yhuang6-desk2.ccr.corp.intel.com>
 <CAFA-uR9ymPTktMbi96cb+smjQHB4Y=8SQfAqmsqTbniGbkGTLA@mail.gmail.com>
 <87il7hjzdp.fsf@yhuang6-desk2.ccr.corp.intel.com>
 <CAFA-uR9n-rKw4k26Bhm=P16jOMtAncRsno7o=yYJ1kTxmB_mRw@mail.gmail.com>
 <87edi4jq19.fsf@yhuang6-desk2.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87edi4jq19.fsf@yhuang6-desk2.ccr.corp.intel.com>
Precedence: bulk

On Mon 09-10-23 13:58:10, Huang, Ying wrote:
> Jianlin Lv <iecedge@gmail.com> writes:
> 
> > On Sun, Oct 8, 2023 at 4:26 PM Huang, Ying <ying.huang@intel.com> wrote:
> >>
> >> Jianlin Lv <iecedge@gmail.com> writes:
> >>
> >> > On Sun, Oct 8, 2023 at 9:17 AM Huang, Ying <ying.huang@intel.com> wrote:
> >> >>
> >> >> Jianlin Lv <iecedge@gmail.com> writes:
> >> >>
> >> >> > From: Jianlin Lv <iecedge@gmail.com>
> >> >> >
> >> >> > Global reclaim will swap even if swappiness is set to 0.
> >> >>
> >> >> Why?  Can you elaborate the situation?
> >> >
> >> > We reproduced the issue of pages being swapped out even when swappiness is
> >> > set to 0 in the production environment through the following test program.
> >> > Not sure whether this program can reproduce the issue in any environment.
> >> >
> >> > From the implementation of the get_scan_count code, it can be seen that,
> >> > based on the current runtime situation, memory reclamation will choose a
> >> > scanning method (SCAN_ANON/SCAN_FILE/SCAN_FRACT) to determine how
> >> > aggressively the anon and file LRU are scanned. However, this introduces
> >> > uncertainty.
> >> >
> >> > For the JVM issue at hand, we expect deterministic SCAN_FILE scan to avoid
> >> > swapping out anon pages.
> >>
> >> Why doesn't memory.swap.max work?
> >
> > The main reason is that deployed nodes  are kept on cgroups v1.

Please note that cgroups v1 is in the maintenance mode with no new
functionality to be added. What is the reason you are sticking with v1?

> Check the code again.  IIUC, for swappiness == 0, anonymous pages will
> only be reclaimed if sc->file_is_tiny is true.

For the memcg reclaim (i.e. not the global one) we try to avoid swapping
even when file_is_tiny IIRC.

> If we don't swap in that
> situation, OOM may be triggerred.  I don't think that it's a good idea
> to do that.  Or I miss something?

Or even worse the system might start trashing heavily over that
remaining tiny page cache.

-- 
Michal Hocko
SUSE Labs