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 2DF6BC6787B for ; Fri, 25 Aug 2023 18:21:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD9222800BE; Fri, 25 Aug 2023 14:21:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A8A922800BC; Fri, 25 Aug 2023 14:21:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 977E62800BE; Fri, 25 Aug 2023 14:21:57 -0400 (EDT) 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 846D62800BC for ; Fri, 25 Aug 2023 14:21:57 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 56F2CA075E for ; Fri, 25 Aug 2023 18:21:57 +0000 (UTC) X-FDA: 81163445874.05.A4FF1DA Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf03.hostedemail.com (Postfix) with ESMTP id 5BC3720032 for ; Fri, 25 Aug 2023 18:21:55 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=eDIt+Z+t; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692987715; 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=nfk4Ajg9vZhcSJWkO4D5es2l67WvnVitf3sD+Mxoc/o=; b=6yURNg9SnHN3Vk63SgTQgZBh63N/6gPx41rfR/mEaOYidXsHXbFJDwCyAD4zQM4U2IEZwb wPD3B1ZVPrHhttrT7ZR9mcLspNorTc1jeJ+cVBvaGW3QKV76gCnqS52GTy59hpUkSNxhwg PK09ZJI31zE5mUYb1vMtQBoGoR1pUPQ= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=eDIt+Z+t; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692987715; a=rsa-sha256; cv=none; b=gEZQuK+K7aeNVwJEqTIBHOWB/pq43ScePsD0E0VgbdoRyeNgjCuG0VZ7Ozu9qA7f6E96D/ bhPBKqVveLdu9bW69LjrT46GKynRk114UUBcCTDh/MZzdUW1tY55N5O/EpHVzHHxIl/lyB 7QOl0Yn9SK2G1Z7bFbXH9915GpSq6EI= Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-52a1ce529fdso1835443a12.1 for ; Fri, 25 Aug 2023 11:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692987713; x=1693592513; 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=nfk4Ajg9vZhcSJWkO4D5es2l67WvnVitf3sD+Mxoc/o=; b=eDIt+Z+t627KQ2EZuZm+87kajqqn1K0HU8KLFxdTLDCtD+wuMKjgaQ0qcwTIwSas49 WVDEYaMECWylUXWij+/jZvNoA9yx94nlAFZ8gWNnKx8KwewXBrVeKKK0QX4ejzgIPAQf My1sCy+8zFZoDJZE7G08x+z+xA6WRPVttme9RirqimuSbFF6j9jfwyGfr54yrjgftsk4 xbmtMURmQ8TxfI7sySNl8Va+n7TPBzz4u5b6jN4EGP9duBqU2b2DEnuCcanhLGxOp3pW 77/h6WaPZTub5smuhLHICbRihdS/4AZopPwU7UN1pi4987SXBEhUn5Ng44/jEuYiINfx ugIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692987713; x=1693592513; 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=nfk4Ajg9vZhcSJWkO4D5es2l67WvnVitf3sD+Mxoc/o=; b=fwSZ2ssVnRTUyQ8hbVB8RnM7wG15Co2uaDamPN6LTT6v1/ujWgJ6ngPZCfOJ32Ce2t PV9cMurZt5WHYosvLP2ztpK8rA9oECr7ZI+Rjds3sZR5k0IuiKMlApPhSnX/GDVZzRF0 5bJZOPXBtQpSdbUwIK7288/pXgR7BU7oSAwAKRjD/RcDkbB3Ez9mcsY4unHVSNb2iRMp /rV2rRI+967+Ce6pfbb1HUOlGCiEeYya85EzbFklWP98TGiuEc91SzNMvGvX+zIKGNQ/ 2YeZWKASfCWx7U3yOtxk+5itwyGaMP2jkiyyje4rbv/SovaYQb85aQEpZIbueabHavtU irtA== X-Gm-Message-State: AOJu0YyNb1gjMkfjqvKxhDiHs6FaTBLUes3CrVID4MwthyEjZlvnr8oq nc2+GbQOWMYCqnek2Silwu/SyaRfCThY6LtS15TPzw== X-Google-Smtp-Source: AGHT+IGWYZ8FgYM5iKDfCxbBg5MabplOImSXSqKxXbXGZbeOf+zbrT7BGOZ8d5lxbtSGnauanQbjJjd+yGbCGWNlAMM= X-Received: by 2002:a17:906:8a41:b0:9a2:120a:577a with SMTP id gx1-20020a1709068a4100b009a2120a577amr4276641ejc.48.1692987713446; Fri, 25 Aug 2023 11:21:53 -0700 (PDT) MIME-Version: 1.0 References: <20230821205458.1764662-4-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Fri, 25 Aug 2023 11:21:16 -0700 Message-ID: Subject: Re: [PATCH 3/3] mm: memcg: use non-unified stats flushing for userspace reads To: Michal Hocko Cc: Andrew Morton , Johannes Weiner , Roman Gushchin , Shakeel Butt , 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-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 5BC3720032 X-Stat-Signature: xwr34xzj6p8p4ax89yy78uxq1d4ngqn4 X-HE-Tag: 1692987715-255804 X-HE-Meta: U2FsdGVkX1887GvEfdEPfIN5fzvCUp273s4EiWANlnYxHs8JUY3w+QNHQ2JX4LpzaCECiNEy3MoaYFLONRUBtS0HDvXBkGz46xTKV4DYUrmQqRa7Ur4NZKuvPlKIDs9bl5ku4z0el7WhMT7u1pTtYO5t679cTFHlclv01dui5fsCf9qBR3K5xOzycVeR3Gg6xL7MI92ICoTWHUQFZFGmo74zCFpvhvE+d4t0dAZLZ8KjAS/QCTdtDmZcbrLGTWd/fdqkhUdTiDBJJ62abtsG8G7H4UsTxxaqJdjppDtzGmy2/s4d/woHcAep5KSq1L5FxVIEn0tdZts0Pc9tXRhumxc8a52cd6jxAXRGnhEw7sFOKJFFlXLKJaijeO1WUsPeh0cLn2Wjr0HBZKOBMg0b6lT5o9E5TmxuigOZyE94a9KbGCbuNyql2VHkGsqlnW9+XpO4TaFOaMarWQWGG7ltq7QknymqW0p+jGrKE3QxWJZWY44QlEVUoUfLnZThGOQa6xTdddO14VlCpTfuZYxF/0I1dlLiCkRi+GQt7LitliUIaBkUAxAlkhb5PA6Dwr0igFAQSxU43Kq1eEk/DTWciusLfEF8zfCCJeEbvSu7p7l4MCmULt+Z9No9NGRouCkz4MJlO5d762BtmVnGc7gTLY7sbyNOd28LxlIBqhn3LNG2iPbajTk8N28UoNk2tnDCjajmQ4Fz6ORnuxySm+UABiAi9UgHvaOBbVl/8oH2L47Ci3K7dmX1WlHvO/+JyJ65GXdSrXBVW4qpYBz8/XRyDVZkZ1yS6+XwxnuALH/ggvExOhVyOdR5RT8ZHSnbS+6zKzp53Jqqihzz6wK80qd+Hayrai8qFHUhvEpLAyOEqedjetbir8K1v2TDfHdYL2p1/cG5BOGsmdN5rZcVxCbOR1qMLaaTVH9ry4Tnf+iR0iILtPSPWRXjG46zm0OldxnC58jd+EVAzD5Nc8UTAM6 eq/Kq2Rr wBFHNmjv4jR57wbm9BZDcoxNhCN6pe5nz4Gf41tNb5SDBpO6EfrRTDt+beW4L1G+GzaKzK9aEDvJEsSpkdMwO+C2wvTvLpmjbQf0JBd5s4x8BcvbzpeIvWTfjXUksKF4bghpUPmdX1R/PM+eo9Q9FkhPNtfZkbZPhpBhb3uvZZcEP7yOIliQW7CH3GRuJmckI8JsvN8iYrez0KVS0TUP4mxs0adHqCQoakDlqYgWLgRgY7UAh4uIpFJwagMyvXkBkQrRp8Wipctk4VhVM+IsdAbcljSZ9QDR//qaD 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 Fri, Aug 25, 2023 at 11:17=E2=80=AFAM Michal Hocko wro= te: > > On Fri 25-08-23 08:14:54, Yosry Ahmed wrote: > > On Fri, Aug 25, 2023 at 12:05=E2=80=AFAM Michal Hocko = wrote: > [...] > > > I might be wrong but the whole discussion so far suggests that the > > > global rstat lock should be reconsidered. From my personal experience > > > global locks easily triggerable from the userspace are just a receip = for > > > problems. Stats reading shouldn't be interfering with the system runt= ime > > > as much as possible and they should be deterministic wrt runtime as > > > well. > > > > The problem is that the global lock also serializes the global > > counters that we flush to. I will talk from the memcg flushing > > perspective as that's what I am familiar with. I am not sure how much > > this is transferable to other flushers. > > > > On the memcg side (see mem_cgroup_css_rstat_flush()), the global lock > > synchronizes access to multiple counters, for this discussion what's > > most important are: > > - The global stat counters of the memcg being flushed (e.g. > > memcg->vmstats->state). > > - The pending stat counters of the parent being flushed (e.g. > > parent->vmstats->state_pending). > > I haven't digested the rest of the email yet (Friday brain, sorry) but I > do not think you are adressing this particular part so let me ask before > I dive more into the following. I really do not follow the serialization > requirement here because the lock doesn't really serialize the flushing, > does it? At least not in a sense of a single caller to do the flushing > atomicaly from other flushers. It is possible that the current flusher > simply drops the lock midway and another one retakes the lock and > performs the operation again. So what additional flushing > synchronization does it provide and why cannot parallel flushers simply > compete over pcp spinlocks? > > So what am I missing? Those counters are non-atomic. The lock makes sure we don't have two concurrent flushers updating the same counter locklessly and non-atomically, which would be possible if we flush the same cgroup on two different cpus in parallel. > -- > Michal Hocko > SUSE Labs