From: Lei Liu <liulei.rjpt@vivo.com>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Kairui Song <kasong@tencent.com>, Nhat Pham <nphamcs@gmail.com>,
Baoquan He <bhe@redhat.com>, Barry Song <baohua@kernel.org>,
Chris Li <chrisl@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
David Hildenbrand <david@redhat.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
Brendan Jackman <jackmanb@google.com>, Zi Yan <ziy@nvidia.com>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Chen Yu <yu.c.chen@intel.com>, Hao Jia <jiahao1@lixiang.com>,
"Kirill A. Shutemov" <kas@kernel.org>,
Usama Arif <usamaarif642@gmail.com>,
Oleg Nesterov <oleg@redhat.com>,
Christian Brauner <brauner@kernel.org>,
Mateusz Guzik <mjguzik@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Andrii Nakryiko <andrii@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Fushuai Wang <wangfushuai@baidu.com>,
"open list:MEMORY MANAGEMENT - OOM KILLER" <linux-mm@kvack.org>,
open list <linux-kernel@vger.kernel.org>,
"open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)"
<cgroups@vger.kernel.org>
Subject: Re: [PATCH v0 0/2] mm: swap: Gather swap entries and batch async release
Date: Thu, 11 Sep 2025 11:04:25 +0800 [thread overview]
Message-ID: <78e45bc6-20ba-48fa-8247-40d745cd7c38@vivo.com> (raw)
In-Reply-To: <uwqrobr5xqtvav73srbe6v2nccgtoy2456vpgzemwex26lwsq7@2g74vl5oomfx>
on 2025/9/11 4:12, Shakeel Butt wrote:
> On Wed, Sep 10, 2025 at 10:14:04PM +0800, Lei Liu wrote:
>> On 2025/9/10 3:48, Suren Baghdasaryan wrote:
>>> On Tue, Sep 9, 2025 at 12:21 PM Shakeel Butt <shakeel.butt@linux.dev> wrote:
>>>> On Tue, Sep 09, 2025 at 02:53:39PM +0800, Lei Liu wrote:
>>>>> 1. Problem Scenario
>>>>> On systems with ZRAM and swap enabled, simultaneous process exits create
>>>>> contention. The primary bottleneck occurs during swap entry release
>>>>> operations, causing exiting processes to monopolize CPU resources. This
>>>>> leads to scheduling delays for high-priority processes.
>>>>>
>>>>> 2. Android Use Case
>>>>> During camera launch, LMKD terminates background processes to free memory.
>>>> How does LMKD trigger the kills? SIGKILL or cgroup.kill?
>>> SIGKILL
>>>
>>>>> Exiting processes compete for CPU cycles, delaying the camera preview
>>>>> thread and causing visible stuttering - directly impacting user
>>>>> experience.
>>>> Since the exit/kill is due to low memory situation, punting the memory
>>>> freeing to a low priority async mechanism will help in improving user
>>>> experience. Most probably the application (camera preview here) will get
>>>> into global reclaim and will compete for CPU with the async memory
>>>> freeing.
>>>>
>>>> What we really need is faster memory freeing and we should explore all
>>>> possible ways. As others suggested fix/improve the bottleneck in the
>>>> memory freeing path. In addition I think we should explore parallelizing
>>>> this as well.
>>>>
>>>> On Android, I suppose most of the memory is associated with single or
>>>> small set of processes and parallelizing memory freeing would be
>>>> challenging. BTW is LMKD using process_mrelease() to release the killed
>>>> process memory?
>>> Yes, LMKD has a reaper thread which wakes up and calls
>>> process_mrelease() after the main LMKD thread issued SIGKILL.
>> Hi Suren
>>
>> our current issue is that after lmkd kills a process,|exit_mm|takes
>> considerable time. The interface you provided might help quickly free
>> memory, potentially allowing us to release some memory from processes before
>> lmkd kills them. This could be a good idea.
>>
>> We will take your suggestion into consideration.
> But LMKD already does the process_mrelease(). Is that not happening on
> your setup?
Hi Shakeel
Thank you for your consideration.
In our product, we have observed that in scenarios where multiple
processes are being killed, the load on the lmkd_reaper thread can
become very heavy, leading to issues with power consumption and lag.
This problem also occurs in the current camera launch scenario.
Best regards,
Lei
next prev parent reply other threads:[~2025-09-11 3:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 6:53 [PATCH v0 0/2] mm: swap: Gather swap entries and batch async release Lei Liu
2025-09-09 6:53 ` [PATCH v0 1/2] mm: swap: Gather swap entries and batch async release core Lei Liu
2025-09-09 7:30 ` [PATCH v0 0/2] mm: swap: Gather swap entries and batch async release Kairui Song
2025-09-09 9:24 ` Barry Song
2025-09-09 16:15 ` Chris Li
2025-09-09 18:01 ` Chris Li
2025-09-10 14:07 ` Lei Liu
2025-10-14 20:42 ` Barry Song
2025-09-09 15:38 ` Chris Li
2025-09-10 14:01 ` Lei Liu
2025-09-09 19:21 ` Shakeel Butt
2025-09-09 19:48 ` Suren Baghdasaryan
2025-09-10 14:14 ` Lei Liu
2025-09-10 14:56 ` Suren Baghdasaryan
2025-09-10 16:05 ` Chris Li
2025-09-10 20:12 ` Shakeel Butt
2025-09-11 3:04 ` Lei Liu [this message]
2025-09-10 15:40 ` Chris Li
2025-09-10 20:10 ` Shakeel Butt
2025-09-10 20:41 ` Suren Baghdasaryan
2025-09-10 22:10 ` T.J. Mercier
2025-09-10 22:33 ` Shakeel Butt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=78e45bc6-20ba-48fa-8247-40d745cd7c38@vivo.com \
--to=liulei.rjpt@vivo.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=baohua@kernel.org \
--cc=bhe@redhat.com \
--cc=brauner@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=chrisl@kernel.org \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=jiahao1@lixiang.com \
--cc=kas@kernel.org \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=mjguzik@gmail.com \
--cc=muchun.song@linux.dev \
--cc=nphamcs@gmail.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=shikemeng@huaweicloud.com \
--cc=surenb@google.com \
--cc=usamaarif642@gmail.com \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
--cc=wangfushuai@baidu.com \
--cc=yu.c.chen@intel.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox