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 697F0C71153 for ; Mon, 28 Aug 2023 17:00:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CE17F280014; Mon, 28 Aug 2023 13:00:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C91888E001A; Mon, 28 Aug 2023 13:00:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B81A3280014; Mon, 28 Aug 2023 13:00:36 -0400 (EDT) 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 A51B08E001A for ; Mon, 28 Aug 2023 13:00:36 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 772E7B2439 for ; Mon, 28 Aug 2023 17:00:36 +0000 (UTC) X-FDA: 81174127272.11.7740BEB Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf29.hostedemail.com (Postfix) with ESMTP id A57E5120025 for ; Mon, 28 Aug 2023 17:00:34 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=Mf0bpwsf; spf=pass (imf29.hostedemail.com: domain of shakeelb@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693242034; a=rsa-sha256; cv=none; b=hQIWIziuiTNPuKB74HxDlk2ACjIxkNwEkdjr50fcALHMabPALhKU0ThQz3BZDBbMXXSwov wCufFNH6SO7Q3554vkvgjY2tnF5Z4KCcEjYNRPxuahmLXN1zT8+cmWO8BHW8/Hg00B6F8C qd9XdriAr/cLMnRW64BGPmu8SkNh3a4= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=Mf0bpwsf; spf=pass (imf29.hostedemail.com: domain of shakeelb@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693242034; 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:dkim-signature; bh=PvhYL8hBy4EhCScbuINCvu74ArNIyYfg31Et1gNQXGg=; b=UV7J+maHlS0zdM16M9RqlvAKIsk+qTvp6oYvf2HYp6cle2zjGYvWQAEkF/hHjaVS+ao1w2 Y/rCvO57fR7WW2rY5EfKqGGNn1l+s8jOpZ0fbFsgiYSIXap/XnCPKj22a2ysCeQGaX5E+k 3UCwx3/sW86s/Ayqtj4YcUWqtKLhT+o= Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-407db3e9669so415031cf.1 for ; Mon, 28 Aug 2023 10:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693242034; x=1693846834; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PvhYL8hBy4EhCScbuINCvu74ArNIyYfg31Et1gNQXGg=; b=Mf0bpwsfOG1A2BIBNX83vxSJWN9TIp9T7qZHqrnDOa8fbUpPAL/gHsvA5MwlVDkFJX eCHrRLSJxvPCTj41QPpAS2ysxMAhFR0FXPGxMUVmNUgmbfS9P4wqQE6jFQ9xq0KZBI7j NsnNe6yK2fGf40k9Mqa5osXiRGPBnzveXUeJF2YNDpXP6CcO4jm5YODDEhlB02T9d3Qy iGCLOzIi1Jm92pKaR8kfgPCkhXfALTafXafzbLRVTF9IYS+ypksyFWuk3X3EYF/NWaPE Kq1h6giRe4yd3nQooDVWaEj/aWbkpmXbxGSGUVoyyDaqaHtbK/ulQmPGdnl6aPr9aiLw oHow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693242034; x=1693846834; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PvhYL8hBy4EhCScbuINCvu74ArNIyYfg31Et1gNQXGg=; b=Zjz/8haKcZ7bvORij8PH4QQlKJ6E8unjJEGVKWkHD5D0RXUcjZF8t4ENLvg55CetUO zhwfXzYLtbzPapbgPFBGSqJxtY0Z8MEVWkPqEcFuLcb+Qr/jo3zbiKO+I81bt942rqT4 WVxTJRd4UKr8/pSEMj6TXrEXi5r4/oRiURpmFd+aSxIzYUB/PJvN/8T1OS3mwphqK1e9 nbHyGwmgkje0oUwtj1lJ+sEuagLYSaeAkcAdtYgkj9inBeM5wWlKMedXRYiyJF3jItA7 5n5Xr7t5GnFbVj0kT18TtQpdHnPlvoezD+BOqPzGJm4FLQY2HT5qfdqGbxcl657COtJF DvLQ== X-Gm-Message-State: AOJu0YyvVgIxvfXMbsBSB9sVYUyrip0FVw5dBDCy2kfd4Vt11l6ZW5Z9 LBgRZeuoJt+GiYRl9Fa3gl4CvibvXiYsieirWJqgfg== X-Google-Smtp-Source: AGHT+IGzOF19YiuEmu+BVGUHysDsySqw7TznjUlMxzpcl63xmqqetr6P7uw061H2B3BhIYP/cdS6CgKuG18Z/j3ZOrM= X-Received: by 2002:a05:622a:148b:b0:3f2:2c89:f1ef with SMTP id t11-20020a05622a148b00b003f22c89f1efmr1750qtx.5.1693242033626; Mon, 28 Aug 2023 10:00:33 -0700 (PDT) MIME-Version: 1.0 References: <20230821205458.1764662-4-yosryahmed@google.com> In-Reply-To: From: Shakeel Butt Date: Mon, 28 Aug 2023 10:00:21 -0700 Message-ID: Subject: Re: [PATCH 3/3] mm: memcg: use non-unified stats flushing for userspace reads To: Yosry Ahmed Cc: Michal Hocko , Andrew Morton , Johannes Weiner , Roman Gushchin , Muchun Song , Ivan Babrou , Tejun Heo , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: A57E5120025 X-Stat-Signature: a5o5fapn5sa99z8o5goen473599xdqhn X-Rspam-User: X-HE-Tag: 1693242034-333741 X-HE-Meta: U2FsdGVkX1/5d0y9KPCj0HN23kqg+4eOcc/yyzDJdeAHTMitxooMOgAQW6PrOR3+vZ7ZH6Tlp9zUtBnVQkVKoRfipo5N1ugXGbFEvmJHTGTagnhH8F08wcgYi9s/E6WpsrCzoITK2TGql88MRyVtaN4VamIUp8rjjLjNSPJJ4vVXR/UsIYNvh9L/ARXySBfkTau1TQeSx5K72EOWXzsOLK8kJNfMzaMcXhrWdyxnVYzmu4y5PgnZox99rcyD0DKKJL0OWPiGy93agoVUlNIIh6aFFjx6fczZvOMBUC99Hh/3mOCO+ozFESD5kaoCL7ruqA6qRIJm3ByoY0Q1IluClrtrBRV0hKUORpln7sG5+Azm13n2oqnx/U7SsWnWWSfGlB5xKQpUwR3LQTRvjJxjQL6ONqZxT2vg9wtSEDs8snU5OcIiw6lqRSDnvp85ggTpjA056mw8q3WE2HeEkD+1mtTuxI0VcrYWtDRoUHcUHs6HJS8/t3C7j5aDGf01SeAeCNaLkY2SDG6fJJ+rV0nJmVGqh/a1TOdgeiOlzSluuzd5JJAKbgfPzL/2Tlx2OB0LbRhdekJchYNBYnQu0JGNcamc0WdTX/pVkiq1MxWs+CVMA5p0+WQ7q9NMK0BoBop1ELI1RPp+Qcs1iEmV4UjBaabeG9V6nAdo+7ETLZyoU8LfjzzOyQssP6b4nSQh8gCxNnmppwN7WQbalPS257hAfuRfSrCyamGE3UxpFdtRRV+51pzkIwhd9Q6nx/9aGIciOU5E1tj/lL92nE+ysHphhmZjQ6N0DKkE2LFQf507oTXkMzM0gl4ghykSmdwzzK/kuZxCAhpLHdO+Xij2KCTL6Q4n0O/gfEuHIQvteuJr9B+Iy9EVUjArtQVXMxu7yA4SNf2ZqPUmei+I6g2ElK5hdbtAAIFs/sw7msG8+zRaflFMBKwZLjsD26ViUQAqkJhPnfKS8ZBliicXvPY1GVG Pz2ZJz3M KKjjXovOrLT6MeBY0V0ThLckuCIch2vFUrgLqcm2L1rh5HKbFwqQ4iKxo/+/685ABPaBxRq7s2r/HNSHjMtL3yGutB9ZfsENS47W6Uwa/sqxeUtx4UnfKhw11c18b/rgrvxBFfVizBF8kzILY4Q0PrsMgnsqTdVBdRbUJEgY4pQzAJqT6o6iy/ZLwNScvfn6p/IczB7hh6kRfFYKrEbq4hW/qTVBTcgSbvAWTCi/SxWakwiWgt5wLn+/cAw== 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: On Mon, Aug 28, 2023 at 9:15=E2=80=AFAM Yosry Ahmed = wrote: > [...] > > > > Well, I really have to say that I do not like the notion that reading > > stats is unpredictable. This just makes it really hard to use. If > > the precision is to be sarificed then this should be preferable over > > potentially high global lock contention. We already have that model in > > place of /proc/vmstat (configurable timeout for flusher and a way to > > flush explicitly). I appreciate you would like to have a better > > precision but as you have explored the locking is really hard to get ri= d > > of here. > > Reading the stats *is* unpredictable today. In terms of > accuracy/staleness and cost. Avoiding the flush entirely on the read > path will surely make the cost very stable and cheap, but will make > accuracy even less predictable. > On average you would get the stats at most 2 second old, so I would not say it is less predictable. > > > > So from my POV I would prefer to avoid flushing from the stats reading > > path and implement force flushing by writing to stat file. If the 2s > > flushing interval is considered to coarse I would be OK to allow settin= g > > it from userspace. This way this would be more in line with /proc/vmsta= t > > which seems to be working quite well. > > > > If this is not accaptable or deemed a wrong approach long term then it > > would be good to reonsider the current cgroup_rstat_lock at least. > > Either by turning it into mutex or by dropping the yielding code which > > can severly affect the worst case latency AFAIU. > > Honestly I think it's better if we do it the other way around. We make > flushing on the stats reading path non-unified and deterministic. That > model also exists and is used for cpu.stat. If we find a problem with > the locking being held from userspace, we can then remove flushing > from the read path and add interface(s) to configure the periodic > flusher and do a force flush. > Here I agree with you. Let's go with the approach which is easy to undo for now. Though I prefer the new explicit interface for flushing, that step would be very hard to undo. Let's reevaluate if the proposed approach shows negative impact on production traffic and I think Cloudflare folks can give us the results soon.