From: wangzicheng <wangzicheng@honor.com>
To: Barry Song <21cnbao@gmail.com>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
Matthew Wilcox <willy@infradead.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
"david@redhat.com" <david@redhat.com>,
"axelrasmussen@google.com" <axelrasmussen@google.com>,
"yuanchu@google.com" <yuanchu@google.com>,
"mhocko@kernel.org" <mhocko@kernel.org>,
"zhengqi.arch@bytedance.com" <zhengqi.arch@bytedance.com>,
"shakeel.butt@linux.dev" <shakeel.butt@linux.dev>,
"lorenzo.stoakes@oracle.com" <lorenzo.stoakes@oracle.com>,
"weixugc@google.com" <weixugc@google.com>,
"vbabka@suse.cz" <vbabka@suse.cz>,
"rppt@kernel.org" <rppt@kernel.org>,
"surenb@google.com" <surenb@google.com>,
"mhocko@suse.com" <mhocko@suse.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
wangtao <tao.wangtao@honor.com>,
wangzhen 00021541 <wangzhen5@honor.com>,
"zhongjinji 00025326" <zhongjinji@honor.com>,
Kairui Song <ryncsn@gmail.com>
Subject: RE: [PATCH 0/3] mm/lru_gen: move lru_gen control interface from debugfs to procfs
Date: Mon, 1 Dec 2025 09:54:56 +0000 [thread overview]
Message-ID: <dc8ce4f329d74a24bde62c93818df44a@honor.com> (raw)
In-Reply-To: <CAGsJ_4x0aVkDf-AhhGbBLU=LCxYFqYoFL0ovij-vFEQeJ46jYQ@mail.gmail.com>
Hi Barry,
Thank you for the comment, actually we do know the cgroup file.
What we really need is to *proactive aging 2~3 gens* before proactive reclaim.
(especially after cold launches when no anon pages in the oldest gens)
The proactive aging also helps distribute the anon and file pages evenly in
MGLRU gens. And reclaiming won't fall into file caches.
> Also note that memcg already has an interface for proactive reclamation,
> so I’m not certain whether your patchset can coexist with it or extend
> it to meet your requirements—which seems quite impossible to me
>
> memory.reclaim
> A write-only nested-keyed file which exists for all cgroups.
>
> This is a simple interface to trigger memory reclaim in the
> target cgroup.
>
> Example::
>
> echo "1G" > memory.reclaim
>
> Please note that the kernel can over or under reclaim from
> the target cgroup. If less bytes are reclaimed than the
> specified amount, -EAGAIN is returned.
>
This remind me that adding a `memor.aging` under memcg directories
rather than adding new procfs files is also a great option.
> Thanks
> Barry
Thanks,
Zicheng
next prev parent reply other threads:[~2025-12-01 9:55 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-28 2:53 Zicheng Wang
2025-11-28 2:53 ` [PATCH 1/3] mm/lru_gen: add procfs support for lru_gen interfaces Zicheng Wang
2025-11-28 2:53 ` [PATCH 2/3] mm/lru_gen: add configuration option to select debugfs/procfs for lru_gen Zicheng Wang
2025-11-28 4:33 ` Randy Dunlap
2025-11-28 7:19 ` wangzicheng
2025-12-01 21:35 ` Yuanchu Xie
2025-12-02 2:53 ` wangzicheng
2025-11-28 2:53 ` [PATCH 3/3] mm/lru_gen: document procfs interface " Zicheng Wang
2025-11-28 15:16 ` [PATCH 0/3] mm/lru_gen: move lru_gen control interface from debugfs to procfs Matthew Wilcox
2025-11-28 16:13 ` Liam R. Howlett
2025-12-01 4:13 ` Barry Song
2025-12-01 6:50 ` wangzicheng
2025-12-01 7:02 ` wangzicheng
2025-12-01 7:45 ` Barry Song
2025-12-01 8:14 ` wangzicheng
2025-12-01 8:48 ` Barry Song
2025-12-01 9:54 ` wangzicheng [this message]
2025-12-01 10:39 ` Barry Song
2025-12-01 13:32 ` wangzicheng
2025-12-01 16:57 ` Barry Song
2025-12-02 2:28 ` wangzicheng
2025-12-01 9:00 ` Kairui Song
2025-12-01 12:01 ` zhongjinji
2025-12-01 7:13 ` zhongjinji
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=dc8ce4f329d74a24bde62c93818df44a@honor.com \
--to=wangzicheng@honor.com \
--cc=21cnbao@gmail.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=ryncsn@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=tao.wangtao@honor.com \
--cc=vbabka@suse.cz \
--cc=wangzhen5@honor.com \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=yuanchu@google.com \
--cc=zhengqi.arch@bytedance.com \
--cc=zhongjinji@honor.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