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 49342EED63A for ; Thu, 12 Sep 2024 18:25:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A6AE76B0088; Thu, 12 Sep 2024 14:25:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A1ACD6B008A; Thu, 12 Sep 2024 14:25:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E2C86B008C; Thu, 12 Sep 2024 14:25:14 -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 70C5D6B0088 for ; Thu, 12 Sep 2024 14:25:14 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 11E4B8123E for ; Thu, 12 Sep 2024 18:25:14 +0000 (UTC) X-FDA: 82556913348.14.71DBF22 Received: from mail-oo1-f45.google.com (mail-oo1-f45.google.com [209.85.161.45]) by imf12.hostedemail.com (Postfix) with ESMTP id 46F3040014 for ; Thu, 12 Sep 2024 18:25:11 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WiGt49Fh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.161.45 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726165505; a=rsa-sha256; cv=none; b=i7qFkUCLL2XB7Ov1eyERxtYpHOytmTb4QF5WKQAAjGRXrcM/K+G8l9QhkHK4d4qs8szE0A BL9pEbFLUm8WXxy/5c/KpIh+1jv43XhnRrUhznEDLMJbmz7NEgk2IlIikKfCeDtaqF+VFf r1J6IUaUSc+k7M1vXRnio6De/EgDwIU= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WiGt49Fh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.161.45 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726165505; 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=b02XjPec5tCJcHnp3AtruWaD0f5QC1gXUlOd8uxHCeY=; b=5DkCoZqqSOqVcI4ebc7Ri8uldwn90NIeewlx0j3vloREwTw1tBP2RpGcB/8X4iq2bxnMnr +0p608SQcqJ1/s2qxoiQD5sKMHDFxsfkau5ghPE8oUJf22RoXhGFm1f6Qb+oYtUqRIvLtW knl2YHJrIKZofx6kTGN8ZGTI28E92vM= Received: by mail-oo1-f45.google.com with SMTP id 006d021491bc7-5e174925b7bso59697eaf.0 for ; Thu, 12 Sep 2024 11:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726165510; x=1726770310; 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=b02XjPec5tCJcHnp3AtruWaD0f5QC1gXUlOd8uxHCeY=; b=WiGt49FhiRv0MfqnVgOwCVedGJ7iJBtIe3zf98XPEGKkRCqhpHGtJqjuVxYbKbCg4h 5NAA6+PQyMB7ZS2iLOXKgeClQqGhiyeWqQn/99Uk+ZQxVa719n9940zQ2pw803b5MPe0 3PjfkaUo6nPYLp8B75xQxlz+nIYRl8eG7Nl2Z245v4om3szbZPGkf+XqJh5oX1BgnVTZ 6YMXfIi413FATJrJF12Tyy5tEev7BNQsvZ9MgzNQVoMbku+lZvEjI6kEQlkuMvzsOnR+ 5YHiM+ytemmZNNA4ULuXAXFNZpkhjjmek36UZxl9FnOgNw3UV6ZCQHwNXxzwMSomlDNq K5hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726165510; x=1726770310; 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=b02XjPec5tCJcHnp3AtruWaD0f5QC1gXUlOd8uxHCeY=; b=Di57thrPbPuIxd+gmnjctAznl4hUFtgX9KIvPPQkWFQiDTTKe8IFDlwY22IZaIkgIB W3x/Zbf4AO7mBiwbTCXimNK+COenTN9oE00Q2ocqujgXNz7FJVGl88oXPBFCCRZ8z/GF 8Jl7O4GzPOmkMGCE7nu4W4wsaajr/9Bm8os7CBnTiKTsDmwBJowCC5E8jW/0qKD6jlXQ JUcUba5Hej7nlnZuueoubdWTtiEfsMIKpIKF+fDasw9FmkFLUvNhWydJnFIZuL4mYOeV q2Wz1tMU/QWNx7B9IvZKkTaU4PK4bFCgpiVDIA6NF6lkTytu45BCRErkX9MtJGHt0DwJ +mbA== X-Forwarded-Encrypted: i=1; AJvYcCWgn3VaJ0Oz6MX3YiU9FM88SGaiSowHS+xqyDK3TKTcBQzfSot4bvglvris2Bg+Jx1qNSTewWcRCw==@kvack.org X-Gm-Message-State: AOJu0Yw4H4gKtxUTh75NL8qiz98EmKdJzY/cRLl6AFpWkPBnGN6kcBBs GgHq0PeV9Pcfgnyusl6KLiczK2OGr2on//iaarfI2rIV+Z5ttcK6do/SbTlDLaMpECpAfZrKOfF d4YvBl2UWI/T40xJpDxzPv4IWGjI= X-Google-Smtp-Source: AGHT+IFH8ql+MLyyOOQSThGtbnUb/CeABolkIrQuSzx3A3cBj6WodG1ullF4+rC5DNHCvcP+wTAztJXpjqnffERLl5I= X-Received: by 2002:a05:6358:71c9:b0:1b1:a8fb:4600 with SMTP id e5c5f4694b2df-1bc3966ac5cmr38751155d.19.1726165509894; Thu, 12 Sep 2024 11:25:09 -0700 (PDT) MIME-Version: 1.0 References: <172547884995.206112.808619042206173396.stgit@firesoul> <84e09f0c-10d7-4648-b243-32f18974e417@kernel.org> In-Reply-To: From: Nhat Pham Date: Thu, 12 Sep 2024 11:24:59 -0700 Message-ID: Subject: Re: [PATCH V10] cgroup/rstat: Avoid flushing if there is an ongoing root flush To: Yosry Ahmed Cc: Jesper Dangaard Brouer , tj@kernel.org, cgroups@vger.kernel.org, shakeel.butt@linux.dev, hannes@cmpxchg.org, lizefan.x@bytedance.com, longman@redhat.com, kernel-team@cloudflare.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, mfleming@cloudflare.com, joshua.hahnjy@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 1n5x7zcrd3dscir7to9dt4etmo6kjc17 X-Rspamd-Queue-Id: 46F3040014 X-Rspamd-Server: rspam02 X-HE-Tag: 1726165511-652018 X-HE-Meta: U2FsdGVkX18MWhcKw8XI1rE+MQAyO9buSaqU0WEMUSwUHrqKCvKvvLgh0rzYye0N4XwJG8hSm8YI4ny7vIFbiI92kKK53Mf3hjZhGcGkKRwhYrD7PHHXVzKdHuGjT8C0db1cJsIfjiuhuuIMC8+ORwgng8ZoCmX+IGaBDUfUuSAdZAP+HeNnH/3f+na+ZXP5PD5tF2FHowou1s/P8MDNHPsu3G2mkWP5GxhCQDQRaopxXyHFkZarZmEkQjMXd3wndE/XlN2TwVzaW8+U5mnGE47GgnuUKiLnmWhwLgrUBQefTEpA6j7dZ4Z1lU+RIqZsqCRcLkTM/01kz4fhInQM5M0ANIq7GjBoTY0H5um+eWeV7clldw3ooN81PeqncNeTAs8vQacPa42gx8Jm8oxveIer7HxvrAcIet69n+LlYMgpZKb/CInc0oYOIPjlD9pqgxlxFof427pTP3vAMcMzCq0pRX2HnzdwDnHCpS59nikbxgd/O7K7TqnQDEt8exlgg5hn3Twjrg3fBOuQ9s79cpQ4TvaRUfsUatC8Z3npbS2sWLWdM04ZdDC4vA48hOb6HK6qBoMy14+FCu+GyVP6wJSALA6eS44T0Te967djssqFo0pcfGMgeYGTdrRzj6UYhcRcDdJRTjjx02LjJPlrq/VIZfr3qXXIrF33ajMSxPXPhoa8f+kWTZI/dXgnQvNxzHaUePmZOqDlt6GTSewiz3RlSBzhLuloKTfr7GI0JV6B7/jEnzCGD13lI3+SEvELD2OB1o0zwlqlFTO9wrXuyAeuScLMYKABtfuhX52obmCvYDWc0VFp9LCif9GtTs+vdY8EnzO7toBQXnZnZiQuXhLtIpdzw8FWk2kjVr77kdscOQl2OXyVt/8MpeWMsXLVKYcR64mElVxIaNX6KyrSyP7R2bGMBEVeHF1qtvzptnkBEdOuRIVCHRwhOzw8bDq+lDyHBWyx6hm+9o0EHB9 KUf0LrlK Izi3YKWHW9gI36Lf3WoCEXvN5GPpQ/8/ytRkD2F9JU+JQ0SFUawR2gIOcN40UYgGd0sUwZxJhTe+tjTWEOvtpH7hb9LXDZOYKWG/h9cnE5V6tYh1+a2V3oZHMm/ywNB151k/vFWnx0L+MqF9iGvurgIAQ/iJdjB7BGmaY46irhk5/03cB2OKaYMdw4NpbLqO4nk1hLFVzcygbIngu8K0U2JQI08QLRF6NB8RsTaG6Dw78YWJ72E3M3Q18tDlsfx+ixEoS/oU5MWFtgTbUWU4jD8r1DIqJLRFeTxeWZDEl4aKxzwdLQRZfbww3CY47igM79/sqfa0Qn5100sV/rsRRw/4wUTBDGAaPf/vd3yYxyEUmAa0sfllz6WFk6deEjTtiDk3IDXHC9ns+GBXUT/debkseNKOcP3rPFE4x X-Bogosity: Ham, tests=bogofilter, spamicity=0.097701, 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 Thu, Sep 12, 2024 at 10:28=E2=80=AFAM Yosry Ahmed wrote: > > > > > I'm not, but Joshua from my team is working on it :) > > Great, thanks for letting me know! FWIW, I think the zswap_shrinker_count() path is fairly trivial to take care of :) We only need the stats itself, and you don't even need any tree traversal tbh - technically it is most accurate to track zswap memory usage of the memcg itself - one atomic counter per zswap_lruvec_struct should suffice. obj_cgroup_may_zswap() could be more troublesome - we need the entire subtree data to make the decision, at each level :) How about this: 1. Add a per-memcg counter to track zswap memory usage. 2. At obj_cgroup_may_zswap() time, the logic is unchanged - we traverse the tree from current memcg to root memcg, grabbing the memcg's counter and check for usage. 3. At obj_cgroup_charge_zswap() time, we have to perform another upward traversal again, to increment the counters. Would this be too expensive? We still need the whole obj_cgroup charging spiel, for memory usage purposes, but this should allow us to remove the MEMCG_ZSWAP_B. Similarly, another set of counters can be introduced to remove MEMCG_ZSWAPPED... Yosry, Joshua, how do you feel about this design? Step 3 is the part where I'm least certain about, but it's the only way I can think of that would avoid any flushing action. You have to pay the price of stat updates at *some* point :)