Received-SPF: pass (google.com: domain of linux-kernel+bounces-110840-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240314141516.31747-1-liuhailong@oppo.com> <20240315081803.2223-1-liuhailong@oppo.com>
 <ZflTCY-Oaxm0U70u@tiehlicka> <CAGsJ_4w0EHuAwvSFuqUsMO-bLjJwCmN_qjL6NuA043-4rgfgsQ@mail.gmail.com>
 <fdc90410-5698-4cda-a7c2-952480c7e7e6@oppo.com>
In-Reply-To: <fdc90410-5698-4cda-a7c2-952480c7e7e6@oppo.com>
From: Barry Song <21cnbao@gmail.com>
Date: Fri, 22 Mar 2024 14:25:52 +1300
Message-ID: <CAGsJ_4xDTS9_NPzKnqZ1vJk2egLVCSSvCbub3oRX8k9MHQFXLg@mail.gmail.com>
Subject: Re: [PATCH v2] Revert "mm: skip CMA pages when they are not available"
To: =?UTF-8?B?5YiY5rW36b6ZKExhb0xpdSk=?= <liuhailong@oppo.com>
Cc: Michal Hocko <mhocko@suse.com>, 
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>, "nathan@kernel.org" <nathan@kernel.org>, 
	"ndesaulniers@google.com" <ndesaulniers@google.com>, "trix@redhat.com" <trix@redhat.com>, 
	"linux-mm@kvack.org" <linux-mm@kvack.org>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, 
	"llvm@lists.linux.dev" <llvm@lists.linux.dev>, "surenb@google.com" <surenb@google.com>, 
	"zhaoyang.huang@unisoc.com" <zhaoyang.huang@unisoc.com>, 
	"quic_charante@quicinc.com" <quic_charante@quicinc.com>, "yuzhao@google.com" <yuzhao@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 20, 2024 at 1:27=E2=80=AFAM =E5=88=98=E6=B5=B7=E9=BE=99(LaoLiu)=
 <liuhailong@oppo.com> wrote:
>
> On 2024/3/19 19:09, Barry Song wrote:
> > On Tue, Mar 19, 2024 at 4:56=E2=80=AFPM Michal Hocko <mhocko@suse.com> =
wrote:
> >>
> >> On Fri 15-03-24 16:18:03, liuhailong@oppo.com wrote:
> >>> From: "Hailong.Liu" <liuhailong@oppo.com>
> >>>
> >>> This reverts
> >>> commit b7108d66318a ("Multi-gen LRU: skip CMA pages when they are not=
 eligible")
> >>> commit 5da226dbfce3 ("mm: skip CMA pages when they are not available"=
)
> >>>
> >>> skip_cma may cause system not responding. if cma pages is large in lr=
u_list
> >>> and system is in lowmemory, many tasks would direct reclaim and waste
> >>> cpu time to isolate_lru_pages and return.
> >>>
> >>> Test this patch on android-5.15 8G device
> >>> reproducer:
> >>> - cma_declare_contiguous 3G pages
> >>> - set /proc/sys/vm/swappiness 0 to enable direct_reclaim reclaim file
> >>>   only.
> >>> - run a memleak process in userspace
> >>
> >> Does this represent a sane configuration? CMA memory is unusable for
> >> kernel allocations and memleak process is also hard to reclaim due to
> >> swap suppression. Isn't such a system doomed to struggle to reclaim an=
y
> >> memory?
> Yes, All processes in the system are also hard to reclaim. and all proces=
ses
> enter direct reclaim. with this patch, much of process which should skip_=
cma
> would retry, scan, skipped in the process of isolsate_lru_pages. and syst=
em
> process will have high priority, some normal processes (like kswapd) are
> preempted.
>
>
> Btw. how does the same setup behave with the regular LRU
> >> implementation? My guess would be that it would struggle as well.
> >
> > I assume the regular LRU implementation you are talking about is the LR=
U
> > without skip_cma()?
> >
> > I remember Hailong mentioned something like " it also trigger memory ps=
i
> > event to allow admin do something to release memory" and " without
> > patch the devices would kill camera process".  So it seems the differen=
ce
> > is if a killing will occur.
> >
> > Hailong, would you like to provide more detail?
>
> psi_event triggered after psi_memstall_leave. much system processes
> perform_reclaim scan and skipped and leave without reclaim any pages.
> the process is fast, so lmkd (userspace lowmemory killer) could not work
> as before.

Can you provide more details?

Does PSI still give accurate reports when processes are stuck in an idle lo=
op
because most pages in the LRU list are in CMA? Also, in such a case, will
the LMKD not receive CPU resources to execute?

>
> >
> >> --
> >> Michal Hocko
> >> SUSE Labs
> >>
>