From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F86EC2BD09 for ; Thu, 27 Jun 2024 08:33:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E1E756B0088; Thu, 27 Jun 2024 04:33:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD00F6B0089; Thu, 27 Jun 2024 04:33:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C96D66B008A; Thu, 27 Jun 2024 04:33:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id AA6A26B0088 for ; Thu, 27 Jun 2024 04:33:08 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 535F31A1C3D for ; Thu, 27 Jun 2024 08:33:08 +0000 (UTC) X-FDA: 82276003656.30.C54037D Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf06.hostedemail.com (Postfix) with ESMTP id 16FEA180011 for ; Thu, 27 Jun 2024 08:33:04 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of xiujianfeng@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=xiujianfeng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719477169; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2tDLQoSZI25+NqijLcscQNYHKvemUsITDAOwWaeid6Y=; b=qXqwmD8qdwVNud2KUu/1HcYLND1pCZvOw7HdkrcaqIzW1PrB8Nfe5565dRroyTS8Ub0iZ0 QGP13vqwREVQDDTKrBHRm84hv0d7IWlXaft0R4LTNsF4k1zj2AqXCafl6j31x11ar+vCZv hnsgruXPcryGUnKfrflFUSa/zmNACP4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719477169; a=rsa-sha256; cv=none; b=WSQvyHF9V4wi9g6nEw7MpRFQ3LIzqmaqnax302pd7iIvld3E6Seedl8xWByE+xL4QGZM55 shmqO4Pz81zw0u9l3L1lDcoGL1073N5IwetKAUMmZ63i+8rkBL8ZujUaFQ+fhY5b4tpqeO KXrSIj1OtC365N3J12HTzz4731s0YnM= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of xiujianfeng@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=xiujianfeng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4W8sCl3yWMz1T4W9; Thu, 27 Jun 2024 16:28:35 +0800 (CST) Received: from dggpeml500023.china.huawei.com (unknown [7.185.36.114]) by mail.maildlp.com (Postfix) with ESMTPS id D80B518007E; Thu, 27 Jun 2024 16:33:00 +0800 (CST) Received: from [10.67.110.112] (10.67.110.112) by dggpeml500023.china.huawei.com (7.185.36.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 27 Jun 2024 16:33:00 +0800 Message-ID: Date: Thu, 27 Jun 2024 16:33:00 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH -next] mm: memcg: remove redundant seq_buf_has_overflowed() Content-Language: en-US To: Michal Hocko CC: , , , , , , , References: <20240626094232.2432891-1-xiujianfeng@huawei.com> From: xiujianfeng In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.110.112] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpeml500023.china.huawei.com (7.185.36.114) X-Stat-Signature: 7icd7qubk8gthjwkcpkuits1mchmspbb X-Rspamd-Queue-Id: 16FEA180011 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1719477184-432960 X-HE-Meta: U2FsdGVkX18jWLv/G47A4EMT05+MWdw3ZoRPHlkKPAGf/mx1J1tQ1p7JUarpvCKHVC+Kc4F3s8nZjo80ZGNLebo7ijfl31R1Vo1bsFwvbEinoKIUHryecR7qPBrV+gyr2p63NhRl39fZgnYDAk/iQRWdk/dGPrjxs6pRyZMpye+kKVRbWpULll8Xa38jTglFH1x90pvWdgJwWilzURZY+7NLhwuUudLF8FuoYVTP3Pv+XCpg9zwRZSovVP9jb/gJo6eoIiwKJFpoS495c4dEIhXWUTUjjy9YdUgNhT9xVngjGWSPBhhWUaNAJBUOu44MEFk1BL4Q+9fqgqUxP602bnzENWMq0dO2puFbRQHYkU+k5OA/DcY8+8ThxOtjx0APmomxp0rluJGSEE2LOeN75crv5+F4ziI/3zTIo6UyIy614+zUcukH0P1j2JqekkXI2BVdaInSTvZyHPfZiraFm6Yh01Q9JfbjmY8FO1GIpguSprrFvjUHjV8/dUB6naaKHz3txU0DHI66FgWvJGuPDhpljDBBPrF4I+OQ0RN2i4gsEPIwhg6l2QEurrGGrgrhv1MFCHQll/Jnl+/azXxpfjQ8QKEl6mIu8BId8OqyjED4WsQHtyj7WSadZCxjXNjoE4siqkQTa+4E3SnWiJsdmJwkoOoFk9bObjK9He7GSiTSH9qfIdYize4Yund8j4a1eqL/NFFDnxvDZDx0HfDYXmHZbut9+vGMVSVyqgU424Nu/sxssnmanL6FTbKoQormZBGokGqKhRBVoZzDme/L1bN3AkTy8FpkDUYDxOHfVRnRVwTSq/d+QjsrcnVbH/x5uRThqZqdpxIIvhdXPFP0UYZPmBZFL3hOEuRcuQEuPX4xgNBGCncVghR48S/9ZfNCOP46238VZTsxlF7U89LRyyDtN2cNi8DIWMtmfAFWPBG5qMWbBz2WYJi1CxqEOuA7K5WhXbECLsIaXrtxw8j UJQI+1m4 roB4ibnTM1Ogm380xoTH8caa2jHl726Jl2St18boBwCPBptjXX/iETvuGfejKrI0JgAFF0pkpwAXpQ9JjoixQHdJdystGPhIekpmkVslOwMAwkni0Ykhp9Jvt4K99wTwFJksj6F30D8mewwqpCKja92ZilUiwoLVDGInz37OUJBt82U5Jr0i15FVh3gsEsRp4eJuAZOe2Cdi2/48= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2024/6/27 15:13, Michal Hocko wrote: > On Wed 26-06-24 09:42:32, Xiu Jianfeng wrote: >> Both the end of memory_stat_format() and memcg_stat_format() will call >> WARN_ON_ONCE(seq_buf_has_overflowed()). However, memory_stat_format() >> is the only caller of memcg_stat_format(), when memcg is on the default >> hierarchy, seq_buf_has_overflowed() will be executed twice, so remove >> the reduntant one. > > Shouldn't we rather remove both? Are they giving us anything useful > actually? Would a simpl pr_warn be sufficient? Afterall all we care > about is to learn that we need to grow the buffer size because our stats > do not fit anymore. It is not really important whether that is an OOM or > cgroupfs interface path. I did a test, when I removed both of them and added a lot of prints in memcg_stat_format() to make the seq_buf overflow, and then cat memory.stat in user mode, no OOM occurred, and there were no warning logs in the kernel. > >> Signed-off-by: Xiu Jianfeng >> --- >> mm/memcontrol.c | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index 974bd160838c..776d22bc66a2 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -1846,9 +1846,6 @@ static void memcg_stat_format(struct mem_cgroup *memcg, struct seq_buf *s) >> vm_event_name(memcg_vm_event_stat[i]), >> memcg_events(memcg, memcg_vm_event_stat[i])); >> } >> - >> - /* The above should easily fit into one page */ >> - WARN_ON_ONCE(seq_buf_has_overflowed(s)); >> } >> >> static void memcg1_stat_format(struct mem_cgroup *memcg, struct seq_buf *s); >> -- >> 2.34.1 >