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 7CFB6E77179 for ; Fri, 6 Dec 2024 08:25:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA0676B01A9; Fri, 6 Dec 2024 03:25:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C4F726B01AA; Fri, 6 Dec 2024 03:25:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF06D6B01AE; Fri, 6 Dec 2024 03:25:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 906C26B01A9 for ; Fri, 6 Dec 2024 03:25:13 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id BF5CD141936 for ; Fri, 6 Dec 2024 08:25:12 +0000 (UTC) X-FDA: 82863848508.01.E945BF2 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by imf04.hostedemail.com (Postfix) with ESMTP id DB7D240002 for ; Fri, 6 Dec 2024 08:24:52 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=g1Dy6TAW; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of hughd@google.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733473503; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=T4v2g8Z1ZmRn1Pa75MapYVMX2K8PJVeT8xzxL8G2PNo=; b=AjJ2tzJqGt+PO45MFIMjkRXMhFKQixNDxBjmEhpfS4//zDR1cT6aJAxdrdGN9SvynZaGnQ 6q5abx90DYW9eXfFczgO7z/biVMVqjEtz/jh5xzgLt2ay1e2fF9EIufv2qAPGp3MAmxsfe XMGJjET8XOB3/j2ueXx9ZdDKp0GuKKE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733473503; a=rsa-sha256; cv=none; b=HBJsYGozOP3HL3InohpLk4tI16vheuMV0pMRErcuhJTMIxnXykUsozVPtg+H/h9jlFnjW/ TL60i8KMf5nRlwiJ4jOvdZGDZkoZxo5aNiwyhcnlv6CK4I7HA8bvrpvmh21NWBrhtGFkjd 3IyTlF2iA4BsmhluiZ0wlPTsI955kbE= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=g1Dy6TAW; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of hughd@google.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=hughd@google.com Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-2eed82ca5b4so1553333a91.2 for ; Fri, 06 Dec 2024 00:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733473509; x=1734078309; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=T4v2g8Z1ZmRn1Pa75MapYVMX2K8PJVeT8xzxL8G2PNo=; b=g1Dy6TAWmtsB7peoir1copR0YgSycOcHgUo0j8FneJ7WQxcZ0AmgpChsY94qHtC0iW BJebhQH+HEe8dXFIAlzrg45d2Qm20YmIwvvhWjDQ6bm1008RZ4PV37XxCzRUw/zD4bQn MLr2fekmkvcreujkGVu3rG92O4EbJb/lsKSS5qlhX/D7fI4G5r9zycU58DEfPhEKefJJ jEnB5Ks4C4svPr/3pl0cvujRqw/1PGUV2VSii2NcjVHqvXTWgEXNFLAGzlFA54L2bkXe 4Pc5CZqtZZu8BRz3S08XZgzamxBy9zkoyZ6PDK/sJiKl/nvVZHmOF1W4qThNK0t18rYY RE/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733473509; x=1734078309; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=T4v2g8Z1ZmRn1Pa75MapYVMX2K8PJVeT8xzxL8G2PNo=; b=ZuoCJTj08nRAviSkdytarXZW0JE6JJJmr5BaQTXyZIqqDEYhYuHiy7qT4W3RqwudRZ LVJJQRv5bJ80PHHQqQ6J9CKDOTbWgcUeyp4Af9D+Qb2zig6TJq2w01Ps186FaZDEhq4Z 0GyzX0MSmCrvgXE8VgEqznne1TYIeuTYSeDc/RsxpywshtvwDbLUcXL13BtlSdfGMran r/+1xf2tqWiLGOdVcYbgmXMk7v2+MH37YWe9bchreXCO4n16C8oTcCwg5JnHdlFFQza5 IIhkIp6DqZN18IUYCY1RbZ2Hhp18QXnonzuLUiV7h+Raha3YRpsbCFIdCKRtPDzZpUuz fXSQ== X-Forwarded-Encrypted: i=1; AJvYcCWPcoEPbOammO4hWKtQQH2NgAWyEr9CYNhPGMbv3dfaY5MQ8kZKNu/bR+mruDs7wM4GR4aLcW7cUA==@kvack.org X-Gm-Message-State: AOJu0Yx5EL/0mC9tQoyLAntW+nNmoTwODKGFQLRxqfRsF0kKoLAlaZiL xSRBb4fpIlvAZOI5LRHwg5BqNzeIuB2hgw8RJWWsq0BVSLOMNjBZq4OfNstwAw== X-Gm-Gg: ASbGnctRjSsRuH6jRsKdlOkZZHmgX85trmBU6KoMxc9CUOg+XUCSgTQkBX+TM8+vkb4 A1BVpTDRB8gm0bBWVyNfAPR4imApdU8DcLgxN+oVlbtJsttQfSirEfseJKSofSfmdZAmhIgEQKv OvP6KNYPAR+QHdLpr3q0/aHSwefLgWGytCpqOCKrY7mh/ziZe9g0Cc45F8So4gV1lqIbjIHcnrH lGRZ2lhsDOT2JNlxiiEo6onIhHK56Hu9RRMuebzioZ150YRnQOkwWZaMB/H61fEcknPKqAyaNVt 0qBadQJI7ikChvI7Pa5TbnCx+0Fm3i+q9g== X-Google-Smtp-Source: AGHT+IGhGKVKP+RqpwLFGFm+XoVmhnZoxHjiIFhVXy65aA/p14u7x09DD7eDaKoDthtQmSQ0FoxSeg== X-Received: by 2002:a17:90b:4fcd:b0:2ea:3d2e:a0d7 with SMTP id 98e67ed59e1d1-2ef69e154e1mr4116058a91.15.1733473507934; Fri, 06 Dec 2024 00:25:07 -0800 (PST) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2ef2700bc8dsm4523017a91.20.2024.12.06.00.25.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Dec 2024 00:25:06 -0800 (PST) Date: Fri, 6 Dec 2024 00:24:54 -0800 (PST) From: Hugh Dickins To: Chen Ridong cc: Yu Zhao , Hugh Dickins , 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 Subject: Re: [next -v1 3/5] memcg: simplify the mem_cgroup_update_lru_size function In-Reply-To: <897b04c9-dba3-44ae-8113-145ca3457cb3@huaweicloud.com> Message-ID: References: <20241206013512.2883617-1-chenridong@huaweicloud.com> <20241206013512.2883617-4-chenridong@huaweicloud.com> <897b04c9-dba3-44ae-8113-145ca3457cb3@huaweicloud.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1463770367-1417733807-1733473506=:9237" X-Stat-Signature: ig554r98br3japt75yn9jtrywkgy5yeg X-Rspamd-Queue-Id: DB7D240002 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1733473492-354487 X-HE-Meta: U2FsdGVkX1+toJa9Kp3bQU/3uX/0PKpc8cgqS/bVg6+uLO1ZRYjFcTyV4rHqQtGCjYT6Ngzu78hgddC1H7YmLOhZ64vG2oekZzm9euLtutmqTtjrCIvZujzv0CySSW8Oq+VuHePqIKAv6G30ulDpRJtjeNY4kiJGotvJiSCy09Bl3dIZ7OtLYdRHaEI7glYO6wW5VbtlBPHvODYAOO48jlE6EBIyjuNr4AYEGi5EUb5BR7lXLtZzAavxYZqOXmGZar5JRNxVVrU3tjA1C+Av+Bp9Y+FZfBqjDuzHSbH+5mgOQmIftv3ctiUgya5K77jxtaBbVbESBuNGSB2SfIrJvC9s5+t4Y12G9L1DCoFwr4WV9pdy74u+LV3qUIFnfwGFc/u1vxXEaNZbmwdZYaQ1cmKkun1Ls9F8M1WJsaMVe3BSrS9nM3+YvrA31mtXsqvHn8eL9v9OGQ0KMjHFeia+EqbX4UBwlozNKbdm0HqOii2ja/UVd4k8AS9xo6QIxVz8Yp+iFIh3lNZ2v8++4phxOn7E6vrBGUJsrdPL4f09fKYUhK6mMV9XuoRzwGzv9U0Lcs0AH+FcKbd2LCadejrP35evzW0XXmLaMfIdHFxlZbc2uVEsN0veYP5NZsb3W1jnVpKWbMc8C9LtC8RINer7paoJqIWDnDr3Wcy0bJ8xxVWmXOk+qnYB/UORjhp12ZAyXHfIE+XQMYSBM7H8SYFcT10KnNgkO7AzX7rpQzY8eutBvWEwn7vEvsnQP7aiajBgC5kW8ILqWOt0xO6qxtkRZG9cN2pNRSGmx9Yy2plMSc9HuUrBIvpG6heiJaljVcDWPCC/ST6rK/ynEzKpyazKlOsAmR6g9N10W5vc774XtzWqC4egqIFmzPYc5GPsPEFguJmt7ZZRdyRG7NUUOiRcNculVHErXGco9lZPs0LxnzZScxDNsEBT8tUNPIqg6UxFTeiRkZfBJtla77J1SfF CLJUp4CH guCPPYqjB/a/V0sSJu0AY4dkaZl7BnFhyxCOSo1QX5PsZa7+6Wc0OLnAlKpnkiwUCP9B9pKyPk3zHAaaTIVoUs0tzDHDL9C2pth5nwThjhvoM65RBs1dLkQjfDh/vi4CQR9RGEuAaaZd/x7Rv+mPuMkLAWfM3qVsfwQNB/HpYtSJrtf704F/SA6/B5lx6YNkNOEvCOtwp0tr0z2Ua8VGGKM51L4ugsU7NtJSFk1M7fRF4CzNfrWwMJTnKeYysOzt50u+5oxsn07e4wh4Jq+8DsIC57a6ZoyYijJCDFLlfuqs372N2c6aO9hjoMaF1Ob76pvFpsQTYNhyXLRvxs08GZ4qFQgMydw9L63WWImolW+v79JEUF4tDhQ5wIg9K1MEE4AWiYEmrDjfjPwdg3lcZbt8//G4nrl+JsoXq/inx3g3liibjCm+DUrejSA2rjZB522/sXozJ7hBFYBXRmD0XH8xLgL0Y3rdSCcdgRtUpIYHegBMCKqeqzv0LpLbRb8vrZvO7MG5VehHhoaApNePTLYXDEg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.004669, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463770367-1417733807-1733473506=:9237 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 6 Dec 2024, Chen Ridong wrote: > On 2024/12/6 13:33, Yu Zhao wrote: > > On Thu, Dec 5, 2024 at 6:45=E2=80=AFPM 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 great= er > >> than 0 or less than 0. To simplify this function, add a check for > >> `nr_pages` =3D=3D 0. When `nr_pages` is not equal to 0, perform the sa= me > >> actions. > >> > >> Signed-off-by: Chen Ridong > >=20 > > NAK. > >=20 > > The commit that added that clearly explains why it was done that way. Thanks Yu: I did spot this going by, but was indeed hoping that someone else would NAK it, with more politeness than I could muster at the time! >=20 > Thank you for your reply. >=20 > 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'. >=20 >=20 > 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. >=20 > 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. >=20 > 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'. One thing, not obvious, but important to understand, is that WARN_ONCE() only issues a warning the first time its condition is found true, but it returns the true or false of the condition every time. So lru_size is forced to 0 each time an inconsistency is detected. (But IIRC VM_WARN_ON_ONCE() does not behave in that useful way; or maybe I've got that macro name wrong - we have so many slightly differing.) Perhaps understanding that will help you to make better sense of the order of events in this function. Another thing to understand: it's called before adding folio to list, but after removing folio from list: when it can usefully compare whether the emptiness of the list correctly matches lru_size 0. It cannot do so when adding if you "simplify" it in the way that you did. You might be focusing too much on the "size < 0" aspect of it, or you might be worrying more than I did about size growing larger and larger until it wraps to negative (not likely on 64-bit, unless corrupted). I hope these remarks help, but you need to think through it again for yourself. Hugh >=20 > I am be grateful if you can explain more details, it has confused me for > a while. Thank you very much. >=20 > Best regards, > Ridong ---1463770367-1417733807-1733473506=:9237--