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;
Message-ID: <771b551c-9604-4e6d-a0ed-b2ecbc42ea4d@vivo.com>
Date:   Fri, 20 Oct 2023 09:57:59 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/3 RESEND] Per memcg lru_gen node stat
To:     "T.J. Mercier" <tjmercier@google.com>
Cc:     Yu Zhao <yuzhao@google.com>, Jonathan Corbet <corbet@lwn.net>,
        Andrew Morton <akpm@linux-foundation.org>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Michal Hocko <mhocko@kernel.org>,
        Roman Gushchin <roman.gushchin@linux.dev>,
        Shakeel Butt <shakeelb@google.com>,
        Muchun Song <muchun.song@linux.dev>,
        Peter Xu <peterx@redhat.com>,
        David Hildenbrand <david@redhat.com>,
        "T.J. Alumbaugh" <talumbau@google.com>,
        Axel Rasmussen <axelrasmussen@google.com>,
        Ryan Roberts <ryan.roberts@arm.com>,
        Kefeng Wang <wangkefeng.wang@huawei.com>,
        Suren Baghdasaryan <surenb@google.com>,
        "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        "open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
        "open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)" 
        <cgroups@vger.kernel.org>, opensource.kernel@vivo.com
References: <20231009025726.5982-1-link@vivo.com>
 <CAOUHufaX35Y6MfwKj_XUWXJwdC=9M=g1gXpQpQghBZ2fXrkEAw@mail.gmail.com>
 <CABdmKX0xevnJfcgsDEWsfX9J5T2x0EV7x-p4ommq_Deg98WwYA@mail.gmail.com>
 <d9b31019-9374-4531-8967-d289af3f4f06@vivo.com>
 <CABdmKX21QfTDXJ2o=CbATmeX1OSgB1XnM=escE7xf8gMrvMhGA@mail.gmail.com>
From:   Huan Yang <link@vivo.com>
In-Reply-To: <CABdmKX21QfTDXJ2o=CbATmeX1OSgB1XnM=escE7xf8gMrvMhGA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bG11SzhzNGFvV0hMTU5yUUQ3ZWJKbnVGOFh3K3haVjRTemtxbjFEYStXWXdU?=
 =?utf-8?B?eDhFd25uKzZvQ1NXblYxd3hvN2Zob2ttVGI2TEc5bnVwWnZUSm45N1ZNZmZq?=
 =?utf-8?B?c2ZXUDhIK0gwTlNSbllMNFIwYUZJeGtxWnlWdkVoZjVXUi93Mm5zRWNLWmVz?=
 =?utf-8?B?ckxJU3VtaHVTYVNiajE2WGZtaVQ5RTBGVkpudU83ZXZqTWovTmk2ZXhTMWtM?=
 =?utf-8?B?T2N5ckw5V3F1SGV3YlZRU2FWNGlEZk5rTnJLV1lVVHVNSkloUy9tZjlsYUR5?=
 =?utf-8?B?MjEyV3JWc3F4cEZDS2JhOGtKNEFDdVlrR3NrRXZxNVcwSlBOSUd6cDd5c1BQ?=
 =?utf-8?B?Rk9paUJKWmZGMk9kVWRhbDdvL0ZqRjNnekZDNitMM3Z3ZVhHcHk4dHd2Z3pz?=
 =?utf-8?B?UUhuWHd4NXRkNVNoNHJFVnpzUzFFM0ZHY0QyS1dxSGZRZzE5dlV5WE5vZzNR?=
 =?utf-8?B?b2dZQXVBZ3B0SnlkKzlQK1g0QjhlMUVPZHhsK0Q4N1ZjWkFXWDBYNi82SXho?=
 =?utf-8?B?WG5QbEhlSWduNGJhU1hNb3ZLNnE3T1dycDBnZWlNQmppVW1ZYmdhSkUrNHFL?=
 =?utf-8?B?L3kzNjRTTVZsOHBJamNyMTVmcTAxV2V2UFZsV1lxWTdZd2psZUdTTXZhMXJM?=
 =?utf-8?B?Y1lPV21HcDhudXlEalNzOGxBdVI4WXI1QVpqdzNMZE9HamFUd2MyUFFXYWZt?=
 =?utf-8?B?eE1PcU42bFV3T2h5bTd4OGZXaUtFL1lFWDZvN1FPK1dCcTJTbjQ2Q2lHcm1B?=
 =?utf-8?B?Nmd0SUlZT2hCbjBJSHl6V3JDYWNJbENGcVE5SUgrcnNZSEM4bUFuTWN1TmFp?=
 =?utf-8?B?N3VDdDdWK3h6dDdZamxlUFIvaWhycUNORjNlbUpGa1g4QXBacnpuWWkrY29h?=
 =?utf-8?B?NU5YTkZ0UlZMdDBwWU8zTGI5SnoxZ3dLVGxoMngyaWVPWThvYkdFSUpCM2JR?=
 =?utf-8?B?K2QwTjlKUW5DeG4wQ2N4UU9XUm9oS0hyaklqSXBNRDdJNGxlNlA1bnBuUjAr?=
 =?utf-8?B?Z0xXZXVkVVRCUTFPaUViSnN3TlFOYWZhQXZqRGxVNnJGdExGd1FBdFdGYzB2?=
 =?utf-8?B?ZGkrVGxTeVVwTm5FYy83VzFBMm9qN2JFblM4MzJqNWZWV05pYnZTNEp5WitT?=
 =?utf-8?B?anhiZWNYYmIxM0JmcU9ITEpTSFhCQVA2emhUWHA2Unk3bkt2UnVodUhvRndE?=
 =?utf-8?B?WVVFZnZNSVQrN2xSWG95VTNuTVlwN2ppMVkrTHFBRkZOUkdVMG1wWHo0NDhx?=
 =?utf-8?B?cTk3T2pVS0EzZnJZUjJTRzVwOStNbnp2bnZua0V1bUhlR1BnM2MxZWd2NmFq?=
 =?utf-8?B?U0RYV1VOdTRiUnRXZFNhQmhRamdhUmt3RGI1OTBFTXZOSHZidGRqUTZLdlZI?=
 =?utf-8?B?U0hzbWMvWGhwbUJLQVo5UGdOVndVcnNaelJacTBBZE11SjIyZ0RWcEFWeW81?=
 =?utf-8?B?QTdJVkJFN0Q1RW1ka0JzcDE1TWpCKzlVaXJBbVFPRGxRa0trTGpFR2Fzemp5?=
 =?utf-8?B?ajJwSHRTSkV2QllGZjlpNVRKMnlxUUM0cCtweVYvTFlZVnBVc3pxSXBreG1m?=
 =?utf-8?B?R3VKUU5MdDd0bWNLNEF5WW1mNXhxb3dVbHM5eStZTnFMSWFQYWlkYVZTWEIx?=
 =?utf-8?B?cTAySXBrSUtzM2J0TGN3NVNjazNXQzhqQ1RWU1VWK3Y1MXhUSzgyYVhjNUxW?=
 =?utf-8?B?OXVYd2FwcCtOMDRDUndhNnh1UmVrTEJQU3ROM1FDeGJqT0hjbzJVV2tTYllh?=
 =?utf-8?B?eG5nMm03TzNUeVhoTy9tamFrbDBzbC90dGJ2NG5DNXBSVGdtQXA0WFF4cnND?=
 =?utf-8?B?QlFKZHg3YS9TWHBQdFlQdXZTZWJSTzR1VmUzL1BYbDN5OXJwKzBZVGNLMEY2?=
 =?utf-8?B?M083QVBFejZ1VGNHY0Z2NTg2VW1oaVA4K3VRZjFlT0tGNXd0RXlUSXBFZ1Aw?=
 =?utf-8?B?dEoreEdkNWQ4VEp6dnF0WDAxb1p1YjBZUEtmOU9nTkRlL3NpTyswcnJXOUd5?=
 =?utf-8?B?SDljWmM5RFF6M3dLSW9zeGYzT0s3NUZzbEErWVpnRHpTYkhlV0pyanc1d3NY?=
 =?utf-8?B?SXJjbFAyQTR2UGlGSzNwVkMxbGkvMHl2Wk5mTVZJNVFKVWJZbTFsZ3dsRUxN?=
 =?utf-8?Q?i70fRPMku99K1yWhXhVEYUFnX?=
X-OriginatorOrg: vivo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c5acc6e-499d-433a-ef13-08dbd11001fd
X-MS-Exchange-CrossTenant-AuthSource: PUZPR06MB5676.apcprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2023 01:58:08.9562
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 923e42dc-48d5-4cbe-b582-1a797a6412ed
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: RRcqK56qLEKjhg76eYNu4EOi8ZNzOfmSUYh+zb7ArHLiRKTpy/EmyaVub6FpTG8mWuxBHAab9Ily+h8cFEW7Yg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SEZPR06MB6197
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Thu, 19 Oct 2023 18:58:35 -0700 (PDT)


在 2023/10/20 0:01, T.J. Mercier 写道:
> [你通常不会收到来自 tjmercier@google.com 的电子邮件。请访问 https://aka.ms/LearnAboutSenderIdentification，以了解这一点为什么很重要]
>
> On Wed, Oct 18, 2023 at 7:32 PM Huan Yang <link@vivo.com> wrote:
>>> Android can't use debugfs in production, but I
>>> think we'd prefer to use memory.reclaim for eviction anyway because it
>>> respects memcg limits and reclaims from slab.
>> Yes, shrink control this actually can use proactive reclaim.
>>> So maybe it's possible to add just aging functionality specific to
>>> MGLRU? It'd be nice to know how you're going to use the aging, or why
>> Due to debugfs not always mount, if we want to now lrugen's info, maybe
>> nice to offer a memcg's node to show per memcg's lrugen info.
>>> you want this version of eviction instead of what memory.reclaim does.
> I think Yu's inquiry was about whether you will look at the lrugen
Thanks to point that.
> info from the memcg file for a production use case, or just for
> debugging where you don't have debugfs for some reason. Because it's a
Yes, for now use, just collect log from it, not have control logic.
For future use, maybe we need to control a memcg's lru_gen anon seq reclaim.
(just assume)
> long term commitment to add the file.

OK, if I can offer a actually use case, I will send again

Thanks too much.