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 2A6B8C4345F for ; Thu, 18 Apr 2024 02:05:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A12F26B0093; Wed, 17 Apr 2024 22:05:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 99B536B0096; Wed, 17 Apr 2024 22:05:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83C296B0098; Wed, 17 Apr 2024 22:05:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 62A0C6B0093 for ; Wed, 17 Apr 2024 22:05:31 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D7DF71C1896 for ; Thu, 18 Apr 2024 02:05:30 +0000 (UTC) X-FDA: 82021010820.20.CE8BAC1 Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf28.hostedemail.com (Postfix) with ESMTP id 1CA65C0006 for ; Thu, 18 Apr 2024 02:05:28 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=sDCRQNL8; spf=pass (imf28.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713405929; a=rsa-sha256; cv=none; b=L9ZoQz3CC+Cx27TAXyWM7RavjSqsnjIC2gWliwAaKgYayuHMKCadziSGnmR8r5KFb1ZhK0 RbfOApQvQeXLVt1DciSD3Jtk8AOS725KhlLjADsK+vEFQrZ3Bu3vpkODlTztni62KNlpKw EuAy/o73g7K+tgdkaJu18mVDx1MXGMc= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=sDCRQNL8; spf=pass (imf28.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=yosryahmed@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=1713405929; 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=T0QnjAhdYrmACiuwAPDxnR5HIy4p9penGkBMygu+5uU=; b=F/yP+XwS5XC18yIjj/NI6L92D5hx7JFDzb54v8wpL1MFfV4qaek9iR9jvpfXft0+l5ahOf rJXQSwCqh7kbMOtRxyQ1GIEL2WFDy9jCO3H/YdzQgLyl1Y+ogezr0mL/sEZzQf2SlHKuQX OrZk+QLthoLQiDNE+8G4Nrm2duj8C7E= Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2db13ca0363so6060481fa.3 for ; Wed, 17 Apr 2024 19:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1713405927; x=1714010727; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=T0QnjAhdYrmACiuwAPDxnR5HIy4p9penGkBMygu+5uU=; b=sDCRQNL8Am8RI+WNwt0FoZfCM4dIOMw9GfHK020PKNVlLcwHTyI7F5d0pIx6UbcSDd qZUA7z5gK2Ex5MLNRqEMh8hZ6PDAPJJIaGTJgVGCs7WS5eEsCwTAG9OUadpWHpa53tkO 9JWpnvYFf3IFOaUOVzZ/5E4aK9JcA8rrFBHND4z+9mXFhnn63b+w0tStdA0zG0LjmbkB ZN6EVmvzQoOwGyHcB7a8YxoY0PdepNTx3//Zn5dgdl5XQwns0HRDy1zZshyqaDDH9noX g/f/loqd0oHmSH3wscb/nsusUMrnKOwl7oFyqhljrl4PaVdkXTF6mgQrnmXtzsAQjwWc GIxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713405927; x=1714010727; h=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=T0QnjAhdYrmACiuwAPDxnR5HIy4p9penGkBMygu+5uU=; b=Ek5slHH+CRM5vrHUYc9eUAmjeYWqrkGZUgs6ZKVmYC0WTM8Ks0GW42HsS/fxKiMZTk GLcL1Aj/7RX/LNK/0hYfm+XcuKB3j8ojmd8gXLxxXLvzi6isNkiecmsPcBtIxeO5I2UI a/vF9fam1P4r9mdSvrNX98j1lqQcdFpSkttPlkAeIZpqtcz7Xp0oQ4IpqxR7wMt+COq5 UgjKi/Zb5sPjTw2WqxHLGlfl+yNXggjp0KbMPMDJkCIxIqcFFldAuIoOyOXrVVs4Uy8E iuDuwv4m4JQmRK1aU3gTtpg/ryFdOk/6kCaCsbODy9rK31U0x1aBDNtteShbsOG9UqOg ylFw== X-Forwarded-Encrypted: i=1; AJvYcCUu5HBpdi9reJv+ZmVjsmEgKPMMzuFkTjkzDdEIo18M/N5Nluud5/+UjIXFuQHFIfkmQB2MNHSnyvV0TUra8upZVGc= X-Gm-Message-State: AOJu0YwoKz1Nfu132NfTLa3e0NLRD1Z5o/jG/ttKiJmnitqY96unvSWy E80jrhJ8bdqBYi0f5Qe7phA1m8Sy8TwDnCxKnxSmgjsrxG4+jTJ7LorD3+0oo3OXcmwUw1RM8ad Q1kBaouxr3ysj0It6/sFZipH0jywSAuprnF9X X-Google-Smtp-Source: AGHT+IFCm3pN2ShD28Z+g4gvIKer7DIONCtgHex5oajrniOoI2un8C3zrZeQwrRhrc0hLYs0bHNGtT9KLILyXzzacvw= X-Received: by 2002:a2e:9003:0:b0:2d8:bda5:c5f5 with SMTP id h3-20020a2e9003000000b002d8bda5c5f5mr644366ljg.35.1713405927096; Wed, 17 Apr 2024 19:05:27 -0700 (PDT) MIME-Version: 1.0 References: <96728c6d-3863-48c7-986b-b0b37689849e@redhat.com> <4fd9106c-40a6-415a-9409-c346d7ab91ce@redhat.com> <75d837cc-4d33-44f6-bb0c-7558f0488d4e@kernel.org> <9f6333ec-f28c-4a91-b7b9-07a028d92225@kernel.org> In-Reply-To: From: Yosry Ahmed Date: Wed, 17 Apr 2024 19:04:50 -0700 Message-ID: Subject: Re: Advice on cgroup rstat lock To: Shakeel Butt Cc: Jesper Dangaard Brouer , Waiman Long , Johannes Weiner , Tejun Heo , Jesper Dangaard Brouer , "David S. Miller" , Sebastian Andrzej Siewior , Shakeel Butt , Arnaldo Carvalho de Melo , Daniel Bristot de Oliveira , kernel-team , cgroups@vger.kernel.org, Linux-MM , Netdev , bpf , LKML , Ivan Babrou Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 1CA65C0006 X-Stat-Signature: 4zeicmi4b8t9gjrzkkm5s51azbu9rgj7 X-Rspam-User: X-HE-Tag: 1713405928-958662 X-HE-Meta: U2FsdGVkX18cU/AH0So9NUNQsCa1+RBsi+U+L1/Dq0B5ds4+lCZlQgfdxnQ5Y3uxxRVsAJvoRBS9lPpV/t55+iYWwtqxKqzhfoXQ2r3TQkghLqWaoLlkL65t2EXjU94KqIRObL306DFaZ4f6BzJT0XBd1sGd2xERQi90QbhCYTjKChMRy1p+oKsqPoaK5cl/Hon4Kq6ew48dY9KkbldJnwvUDAQbKmXEcwlAPEfOrEc5vjv4oi5SkCVmOM1RpHfRsULVeKel7uppsfjcy8LgrZflDeDUGBKf2Vtr9sxrFarfQYKuj/Dz8rGRi0LH9nz//DUVPipKRKq3NQw1X6UZ+jhKnltv4Aqnnf48B8ZEqFN8hrMhth/RR7IGhWiKI5LXHJCmIYtJovqc6T951BS70RrSnajvTYw9HZjdBxsOpcopm/61xvm0YAPSHyhc2Xe9bD60wh/S0DlFpea+E3EdgfX6iUan1DTOZijOFXifteJEi9TEq4PYR6nKeAdSPyT3Qptx6JoXC9BD4iPXxrlKJV9WlPy982E9vZcEQOqS5buv+SIC9ToGpDwUI2lLWIbO8+iKxf+aqhe074aCQ6WXIO+/pqLsHcW1irm6EnZIHtU+w1Bxcll0kAvcItg58AcxmLf9bu9wVug1H/6u7exaqOSNtkdaTdoNQW0ZW1knjaMYLKnjpgukCer2Rtfpbk/GzxPbN02XRIFNesQzfXZ4OL8RoxxDTcASo/gJbzu23Ab2VkSxnrokZdjFOrOD8P6rn6E/Eub/ROoM+t4nbi70+1a84WChH87k5VXqCJOz8r6YgFYnB58QFkIMvYwGO1eVs6R/X1KTM7RTCFhhcb1n7aoEm2a9auaMcAYoIs1Mc0B6rRgzmxqOgRk2PHQHlswg3mXGE8XL4t/S1yOOrTOGrDKXYpuWKmoxV7mNBq2UWCslIy1JctJTZLuOo4M3+dW1FRF4O/oFaxPDODVo9qn x1fGL4iV 6S9mPenUMgpblRCea373zvL2mxSN6pArs+2gJtlBFsOKV1UUob6Yod44ngivmyhlhuQF+kG5LMx3xHzkOqKmG4lhKD/wlgGuN6gcBHg3J8AnIphp/Xx71Ch2zYXXnyjLvkF84WFBiRj+9WE0MwNR1rcU+Y4h0kBJOPsyVC0/Mexh/IOEz3pyu/+Mf9ToB2q5Ja4do7wTUXnvbkbdO57OcmLsy9clV9FZJoPumyRe5FGMwb1S90zh0ANyw0Y5KNkc7r71ic97PACbXrSvPKra6RmNJ5jGbkQv2YqUxzgFMS+EAwVdfCMunV1KaVw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.060194, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: [..] > > > I personally don't like mem_cgroup_flush_stats_ratelimited() very > > > much, because it is time-based (unlike memcg_vmstats_needs_flush()), > > > and a lot of changes can happen in a very short amount of time. > > > However, it seems like for some workloads it's a necessary evil :/ > > > > > Other than obj_cgroup_may_zswap(), there is no other place which really > need very very accurate stats. IMO we should actually make ratelimited > version the default one for all the places. Stats will always be out of > sync for some time window even with non-ratelimited flush and I don't > see any place where 2 second old stat would be any issue. We disagreed about this before, and I am not trying to get you to debate this with me again :) I just prefer that we avoid this if possible. We have seen cases where the 2 sec window caused issues. Not because 2 sec is a long time, but because userspace reads the stats after an event occurs (e.g. proactive reclaim), but gets stats from before the event. [..] > > > > > > > With a mutex lock contention will be less obvious, as converting this to > > a mutex avoids multiple CPUs spinning while waiting for the lock, but > > it doesn't remove the lock contention. > > > > I don't like global sleepable locks as those are source of priority > inversion issues on highly utilized multi-tenant systems but I still > need to see how you are handling that. For context, this was discussed before as well in [1]. [1]https://lore.kernel.org/lkml/CALvZod441xBoXzhqLWTZ+xnqDOFkHmvrzspr9NAr+nybqXgS-A@mail.gmail.com/