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 BEAEEE77173 for ; Fri, 6 Dec 2024 06:41:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CD1B6B00FA; Fri, 6 Dec 2024 01:41:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 17F326B01A1; Fri, 6 Dec 2024 01:41:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F39236B00FA; Fri, 6 Dec 2024 01:41:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D09816B00AC for ; Fri, 6 Dec 2024 01:41:04 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 52C1D1C7C95 for ; Fri, 6 Dec 2024 06:41:04 +0000 (UTC) X-FDA: 82863585630.17.9655EB3 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) by imf12.hostedemail.com (Postfix) with ESMTP id 5A90F4000E for ; Fri, 6 Dec 2024 06:40:53 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf12.hostedemail.com: domain of chenridong@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=chenridong@huaweicloud.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733467247; a=rsa-sha256; cv=none; b=EPVeXPLkXJgZehpMEabQ/azSxKvUOiJDfXBKwdQ6jCNvM0ovuEtdsyxPEneB67oUhLqwsS HcoP2a+ckpZePTLz64YJetLv1+49O8NBM658axl01/FgUyBElQ/Iowsq6qZTgsWiMb3XuB lhCdJOcUSDpWysQmu11RDCdVXlQz7EY= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf12.hostedemail.com: domain of chenridong@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=chenridong@huaweicloud.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733467247; 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=AU4+4KmB2U91/bJhk9QcNEYC87O6QC/x/A678LuwIoI=; b=4BeAJwa+Rx/rusZAqAKIPwQYrHyCf1y2IRGBnKz/S5C/x8v7etA/dJB2vc37eV931vK16v a5riSdA7p8C5cG6YfByAeXGYRivp/NmLdjMnzswvGAkVy/9lMN8AkL1mVcl42SfkXwpkMV ZCXzFdKnVlOjRXQNC1hyl+qGztVZ68Q= Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4Y4M8M3nXQz4f3jdR for ; Fri, 6 Dec 2024 14:40:35 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id 97A051A06D7 for ; Fri, 6 Dec 2024 14:40:54 +0800 (CST) Received: from [10.67.109.79] (unknown [10.67.109.79]) by APP2 (Coremail) with SMTP id Syh0CgA35uJ1nFJnECUdDw--.53652S2; Fri, 06 Dec 2024 14:40:54 +0800 (CST) Message-ID: <897b04c9-dba3-44ae-8113-145ca3457cb3@huaweicloud.com> Date: Fri, 6 Dec 2024 14:40:53 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [next -v1 3/5] memcg: simplify the mem_cgroup_update_lru_size function To: Yu Zhao , Hugh Dickins Cc: akpm@linux-foundation.org, mhocko@kernel.org, hannes@cmpxchg.org, yosryahmed@google.com, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, davidf@vimeo.com, vbabka@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, chenridong@huawei.com, wangweiyang2@huawei.com References: <20241206013512.2883617-1-chenridong@huaweicloud.com> <20241206013512.2883617-4-chenridong@huaweicloud.com> Content-Language: en-US From: Chen Ridong In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CM-TRANSID:Syh0CgA35uJ1nFJnECUdDw--.53652S2 X-Coremail-Antispam: 1UD129KBjvJXoW7ZF4rCryrGw48XFW8Ar43Wrg_yoW8ZF15pF W7CFyFy3WkArW7u3s7twsaq3y2krs5JFWUXF9xX34fJw1j9FyIkF4UtrWYqrW7AFn5Cw43 trZxWr1vyFZ0vaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I 0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40E x7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x 0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lFIxGxcIEc7CjxVA2Y2ka0xkIwI1lc7CjxVAaw2AF wI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4 xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r4a6rW5 MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I 0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWU JVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUF1 v3UUUUU X-CM-SenderInfo: hfkh02xlgr0w46kxt4xhlfz01xgou0bp/ X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 5A90F4000E X-Stat-Signature: yucnwq1koafzmwc5mbm3rmup9uiwjpub X-Rspam-User: X-HE-Tag: 1733467253-238622 X-HE-Meta: U2FsdGVkX18gKa+bFPaBz3VgYDmZu2CaQPfOsuK3STqHe+XFXrxplHiuh6jA7kyUf3e5CO7DOy/96NEwLCXwG1ucJQ8FRq8VrIosUilvyhZQf5L1EbhwFCsGpQTh3fSu8yo8Vemokux1iFdUdqxbvnl6oE0/s3lqJkZCiYOjSHMWivwykyEBlitb2x6aS0cLz8CwD/MIFqfs/CamUAL7SW4N4ZlbuOOMyQSk/d3RzbkKe4L4UdNI3SZyiAzfvZ+8++R3PwJWI4ziITGbeYWdp798QOIrP7yA7p9UUP73mfgkxquKn1kR+ZqI1UFXN6M6ml6CDFJy7NYMeSvjE18pIJZgBoFvvbGXJq4Be+lmPNGUn2alCa/1Y0r6vcVm8V+etNnDMhSFjOTpDXKFFLSKNXsGI0Y6wzk1mWry1zCJWCQP2SaUMkzUgFuKNFQ70QPGVYXWhL/2nHGtC/DiXuovJDBNrBjNOcv8UXBnBP/dXVe2nTmiD+uTlo+1pREwk7SbdIkmCyQ7dnHCc8mTKU3seobogRAECU7H0fjClh4tfHFta+p5jmKwl+SQnuKpfpCkSUxqWq0MiTusVeCm4wy+WxlcoD2JhtgoAseOfrpvn802JC5UVkmGv8EwOQEuNdiYVOQAhBKh8BWoO4p4Jy/xC0Wai9VryYrPs3oBP8PN1j09aALRvl7kk8lpnbeOKxxdFTm2xqJZc/Hz7szlPtNvA05Vf92k+vNSHB8BjbFRi6CW2Xk7xEhIdzY/i9nzzQn2FO5kSwW7Y3uscbmpqd3LWb+6VWY/qPTm79tnVQE2ABOx1+HwPRGuSK2ETQmPmEMgR8d2lpONTGuuT3aMMOKgKkTiMDXsVVTk9Zjy4y8ac85opThpqWPFfTVM7UnLX+Y1D4hTzSA1vJljyn9R9rOKA65eaUm6w1+3rw8ye+8cLsSOoWJEtqja6Cy/Ql/VhnLZcaGv9beuWa3hzHqQHt9 iNFhcXXT EdNCf7eAVg6x8oWw6eWxGlkDzf/nRUTN2Ew6gU+8+q1+o8fbYNfPXpu0AYjyR1HPesCfblNF7wCcQosa9uVXa5GpNZtH/CXzCV2geoPIrWJKrHdyJGPjSfeUF8agNJmNT1yHvGR5EFisDbZP7dg8/lEdt4BOyopKekAnUrkDa0RyEq9OeT+nJDTqWf2KYVy4nGJH4+gC2cIlLzvNL4/VH1jFnCjvY8F6b/pLZoqwM+Sbg9TsZPpKP8CvXFsoolNY2eKFB0QpaDnADniDXxpe8MicWrA== 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/12/6 13:33, Yu Zhao wrote: > On Thu, Dec 5, 2024 at 6:45 PM Chen Ridong wrote: >> >> From: Chen Ridong >> >> In the `mem_cgroup_update_lru_size` function, the `lru_size` should be >> updated by adding `nr_pages` regardless of whether `nr_pages` is greater >> than 0 or less than 0. To simplify this function, add a check for >> `nr_pages` == 0. When `nr_pages` is not equal to 0, perform the same >> actions. >> >> Signed-off-by: Chen Ridong > > NAK. > > The commit that added that clearly explains why it was done that way. Thank you for your reply. I have read the commit message for ca707239e8a7 ("mm: update_lru_size warn and reset bad lru_size") before sending my patch. However, I did not quite understand why we need to deal with the difference between 'nr_pages > 0' and 'nr_pages < 0'. The 'lru_zone_size' can only be modified in the 'mem_cgroup_update_lru_size' function. Only subtracting 'nr_pages' or adding 'nr_pages' in a way that causes an overflow can make the size < 0. For case 1, subtracting 'nr_pages', we should issue a warning if the size goes below 0. For case 2, when adding 'nr_pages' results in an overflow, there will be no warning and the size won't be reset to 0 the first time it occurs . It might be that a warning will be issued the next time 'mem_cgroup_update_lru_size' is called to modify the 'lru_zone_size'. However, as the commit message said, "the first occurrence is the most informative," and it seems we have missed that first occurrence. As the commit message said: "and then the vast unsigned long size draws page reclaim into a loop of repeatedly", I think that a warning should be issued and 'lru_zone_size' should be reset whenever 'size < 0' occurs for the first time, whether from subtracting or adding 'nr_pages'. I am be grateful if you can explain more details, it has confused me for a while. Thank you very much. Best regards, Ridong