Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Message-ID: <d9b31019-9374-4531-8967-d289af3f4f06@vivo.com>
Date:   Thu, 19 Oct 2023 10:32:15 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/3 RESEND] Per memcg lru_gen node stat
To:     "T.J. Mercier" <tjmercier@google.com>, Yu Zhao <yuzhao@google.com>
Cc:     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>
From:   Huan Yang <link@vivo.com>
In-Reply-To: <CABdmKX0xevnJfcgsDEWsfX9J5T2x0EV7x-p4ommq_Deg98WwYA@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?dWw0YWp5Y1diZWtnd3A5VUhQby9ZRjdLSzFOVDYydU9tM3FIaEowZXV4T2lX?=
 =?utf-8?B?a2MzWlhyRkt5M2d4eVJJb0FWMnZ3WXRtN1BJY2tzZjgxUUlGVUU3bkkzZE5M?=
 =?utf-8?B?alRva2VMWkdKMldHMzZVb01mN3N2RFNsMUtqT2cyaUFXZFBMUmg5YkJSZDBE?=
 =?utf-8?B?bEM4aDFpd0tuMmg1ODNEcXdPQ2lyeEVWVXZPTmJqNnl1V1R2a1gvR3Y2VzJI?=
 =?utf-8?B?UGFxdHpadzFlQitiNUlhUGpUeXlkQWxNY1RyUnNtZ1JvZnBMTlJGMnltRVg5?=
 =?utf-8?B?eEZadVJuMTZkSlFUSzY4bk1EU25VMmlCMTVRQndLOThzVks5SGtsQmN1WjZm?=
 =?utf-8?B?ZUpsdnc2UUtZRU9FWTJVSjRJUmdPVDVpeU9vS052UWNsZUhmNGVhZnN6a2E4?=
 =?utf-8?B?ektoK1M3anZiSU5sbkprTFhkcXpKWTlhZFNQWXlndFlGKzI0bHlYbHhIMUov?=
 =?utf-8?B?ZklwZDJhY1BwdGhMS2ZLNitBSVZQTW55T2tNQStNQ04wbTVGd1I4VUErMmtO?=
 =?utf-8?B?L3lYYi9KQ1c4bTFYQnhndE1rYVlJVkNxc3pYOGRMd3lxRCtYeTV1a1pqbGtT?=
 =?utf-8?B?bmQrbWNzQ0lQUTR3VHBMVUVnYStpK25qcy8rMUlvTUxERUxWUlpqNjlXWFFs?=
 =?utf-8?B?MzFTMDZnb1V4M21wb1ZEYnY0NEFJYjE5OTMvOWo4VFlKRW52SFcyQUoyVmxG?=
 =?utf-8?B?bVJCbi9Za1Fwc3R5Z0tJQ01xN1g5L2p3RGE1dkZoTlo0Wi80K3N5SGV5L21O?=
 =?utf-8?B?WU1wdlFLM3lKM2oyVzc4OXYybWp1UWs4cFlWUnNTWXNKcFA3d0tNS2VOenhF?=
 =?utf-8?B?UnJzS2xVZkRWVllvU3JQK3R2YUs1TTRxdnV1c1Q1dlQ2UHRVSTRGYjl6K09D?=
 =?utf-8?B?eVFTcWFiZThiTjFIUjlmN2FKeHlXaWtFOXF1OXVydlJ4YVM0NGljOWpTZG9l?=
 =?utf-8?B?aVVhL1lTODBRbUlHZVRLc3pta2tVcnpIS0ZsRG95b0IxTThuejFJYzdLYUxO?=
 =?utf-8?B?Umptbyt2YW4yZm5zZ3N4QTN3MkhXajBRZ2hoQXNSeTgzK25xZlVHMFNpMHhM?=
 =?utf-8?B?UHNNU1NwcTR5Si9NQVVCaHZmMGlkQ3BnVis4R05rYWZTd1c1TTd2Q1VXWC9u?=
 =?utf-8?B?R0hxU2YyQklVamE0ZFNkaVppMndORHRmT0FIVWdsUnYyYjZEZ01ZMS9SbThF?=
 =?utf-8?B?VDkvMXd4SVJRU0F6WFI3R01Bc25UWDlSNEVkTzJrOU1ZdEc2MlI2Q29BMldp?=
 =?utf-8?B?aGhJOWdQNnJnYXdLWGVMMDJiT2RnenM3ZHZGREhLWlB0ejhnUzBweEtMYk9H?=
 =?utf-8?B?d1E5WGRsUnh1cloycE1DcGpYM3M2VlB0TW5Ya1lXSFgxdkZEMWwwQTVBSjhW?=
 =?utf-8?B?ZTl0cDRManhHSDN4bkk2bU1MRGdSalB0M0Ewc0duUEIvQ2JhNkM1TG1QcWhY?=
 =?utf-8?B?Z0lGZE9SNE0zem5DZUFnMXBUYnZJY1ZCRjJwdlBpMWpPSTVWWXZ1VTR6SGxF?=
 =?utf-8?B?RVZVOURhaFdGTXh1MEY0enNKaWdteWJNK0RPYlI0WlZJMXpTQkZBeG00UHBD?=
 =?utf-8?B?SjdqQWVBSkp4WG1SdForR1NyY0xnYkNFbytCRXVEd0o0S0E2TU9XYlUwWkw3?=
 =?utf-8?B?NzMybTQ0OE5ZM2tWRHhjdDdVRDVWM1ZlbGNGWlIrTmhkY01XVm9Ya2FjMjFn?=
 =?utf-8?B?eHFzU2NIcFc1UmlUNlhBOTF0a1dLTjBQUEsxSGpDdWQwSmpkQ1ZVaGt4eE51?=
 =?utf-8?B?ZzZrenpzOUtEdG1PVjNvY29XakR3aGYyeEtNVER4Y2R1QkJnNi8wVWdYaW44?=
 =?utf-8?B?VzlLUkVsSlpZOGZkaE9IMjhCMkhCVWwvN2hUZXN5a2orWnlncUhDOFJoeE5W?=
 =?utf-8?B?eFlGbTlHOGhnWGx2M3FjeEJDVFVJa0dGUGJRcUpjOWV3eUNCR0Q2NU5RTjF4?=
 =?utf-8?B?US9ySU45bVU3N0R4Q0o3YzhHWEpsUzA0NmNvVzZNUE5mVCtZVlZ6cTFxd0tB?=
 =?utf-8?B?R2dCbllwMldJK0kwQnhBSDh3aE1vVVVkeGxWZ1VsK01NRDRwUlNkWEZwWUJP?=
 =?utf-8?B?OHYrUHl2bkg4aUl1aGdtQkZqS3J2bmEvbTZDV3poM1pKdWJHTERUajRvcEpV?=
 =?utf-8?Q?3X15lRu+XZcNpNxmt1PhB6bMz?=
X-OriginatorOrg: vivo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 097ff8db-c5a0-478c-abff-08dbd04b9f8e
X-MS-Exchange-CrossTenant-AuthSource: PUZPR06MB5676.apcprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2023 02:32:22.3433
 (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: aVQpWOMLi6FPXTs0A6lqvvrhvRHArYI7A8UgQQs3BLLtDi085LwcG7YCdPSKowBbE7jU8GhROoVaO1x4PUndaA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY0PR06MB5756
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 groat.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 (groat.vger.email [0.0.0.0]); Wed, 18 Oct 2023 19:33:49 -0700 (PDT)


在 2023/10/19 3:59, T.J. Mercier 写道:
> [你通常不会收到来自 tjmercier@google.com 的电子邮件。请访问 https://aka.ms/LearnAboutSenderIdentification，以了解这一点为什么很重要]
>
> On Wed, Oct 18, 2023 at 9:34 AM Yu Zhao <yuzhao@google.com> wrote:
>> On Sun, Oct 8, 2023 at 8:57 PM Huan Yang <link@vivo.com> wrote:
>>> On original global lru_gen node in debugfs, it can all show each memcg's
>>> lru gen info in "lru_gen" or "lru_gen_full", and can type cmd into lru_gen.
>>> But which show info contains all memcg's info, and cmd need to
>>> know memcg's id.
>>>
>>> This patchset add lru_gen node in per memcg, with this node, we can
>>> get lru_gen info in each memcg.
>>> Also, we can type cmd to control each memcg's lru_gen seq, but, this node
>>> don't support multi cmd, single memcg just process one cmd once time.
>> Adding TJ from the Android team. (The other TJ you CC'ed is from the
>> ChromeOS team.)
>>
>> This series introduced a new ABI, which has to be maintained forever.
>> How exactly would it be used in *production*?
>>
>> Android doesn't officially support memcgs. So I want to understand the
>> real-world use cases first.
> Not sure how Android came up but I'm happy to chat. We want to turn on
> memcg v2 for Android but I'm currently working through perf impacts
> before that happens. 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.

So, this node not want to instead of memory.reclaim, it's good enough. 
age or other control just flow debugfs global node's behavior. If no 
need, delete write is OK.

Thanks