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 79E39C531DC for ; Thu, 15 Aug 2024 00:23:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E0E906B0083; Wed, 14 Aug 2024 20:23:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DBF696B0085; Wed, 14 Aug 2024 20:23:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C85C06B0088; Wed, 14 Aug 2024 20:23:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A98D46B0083 for ; Wed, 14 Aug 2024 20:23:15 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4DCC6121278 for ; Thu, 15 Aug 2024 00:23:15 +0000 (UTC) X-FDA: 82452580350.16.485C90C Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) by imf13.hostedemail.com (Postfix) with ESMTP id 726FF2000D for ; Thu, 15 Aug 2024 00:23:13 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mRUU2YmA; spf=pass (imf13.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.41 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=1723681357; 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=Cw5dTcrztz9RxH0G8Zi6diIKTPcCBLS7HGD6iPgP970=; b=ZWEyR+r/pWdpewwTei2U6pZqJQZspKiK5WgtnJVCQpJYv6n6nzfKEVYwSypk5Xmj26Qqk0 muItezVk7Sz2xtVQOmrtkY8h6BVzmPv5PKonvV/PXy16Gw55G9LvvbV1RIuH2LpOr+rdtJ PJ7xe58JP236HHt2O5HzHGkSuE1k+is= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mRUU2YmA; spf=pass (imf13.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.41 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=1723681357; a=rsa-sha256; cv=none; b=5H6xO5464+/kgzg/FpcF17viweg33zAAu1GI8gzRnjDdskpiXx6GVUQ3yT9Ek93/sZ47e5 tpPV+Dy58uw1BdxLKp3dS1orK24I7ZNM8Lt/fd3OP1aJZ/NMxbf0lRQolDaaYOAL685e5Y ktQgbDRco4bAt4y4aghAWiEk/prPbEs= Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-a7a843bef98so65285666b.2 for ; Wed, 14 Aug 2024 17:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1723681392; x=1724286192; 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=Cw5dTcrztz9RxH0G8Zi6diIKTPcCBLS7HGD6iPgP970=; b=mRUU2YmADPc/0taSXvVlZR9mVSg32sKfM3zp1ykr3Wsp5bKcRor4kJ2sjbI+n2D49B HdGGWJwD2F+wauYctnvBNw7opjxb5PpPrkiLkYKOBW2dG8ScpSG7of3H4FmV1XO5CAKd ZjzzoxhgO+jVGNuHVB5IGRj3yV1bSyp5upQje3t+2sjFepq7WmL3vQfTW+TVT4ojJin2 I85XNjGmvG4T6p8OH8LTHxDpzxt0HsFbqUPCcDSUIexfKQTNTWAekLjuBuAYyhSfG4dY jToyVsbR92X3prw4iighOsaq0qAzR5hqG4+njGXD6ZeafclYvQxqIk5jVzJEyMBLGdDH TatA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723681392; x=1724286192; 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=Cw5dTcrztz9RxH0G8Zi6diIKTPcCBLS7HGD6iPgP970=; b=Tk4VCTK45K6nnEyzyHIRzwpbdWQEYadjeVk1flTv/BMyr7XQmte6ESI8MG+1Pqm7qf VHj80DpoqO/TghZOmj5O4mSC7crYqWN14J0u57HAHdU2QgBj5q32+fvMkxc48Ecs8Ky9 25beZNk+LZJKKF4hI44Km5vSCCZWiIUQJE8P5Tkj+okH0zZS/1sclf3cXMX0/fET/CXA LH8MIRxhrm6r6c62jRqiYQH0DcwwzBN2mw74/F5CP7JpMGuRXjztZi8QYZ32svlm0HeL 4TykAjEh1CCkmRByZlP8TTcBPylZ89MTuVXVFRkzSS+Xh/P2FSmpUUl5w2ylfUuD1tfp O1zQ== X-Forwarded-Encrypted: i=1; AJvYcCVUyLIzSfkkkJ/NpIIE8QW9fWqLWLyUQWsBkvy30jUKw3YNciJFyhTPOi3+ZOTSp9mIvCeZHJW1Yw==@kvack.org X-Gm-Message-State: AOJu0Yw981bd0gnbjxhYu7reo4ibGaqyEeWNWsv9tmfMvyJBX5OGxrBg djZpCyAo9J9HU8VQtKbFePp/NNNdnPHgAMlVEU2PJd6aF57IQNZfxSJ3OplxfC6NGrOh6LiTJ66 dYUgciA+l6sOmHqGNN1p7y+DrjxgTBJPFk8jO X-Google-Smtp-Source: AGHT+IFC8o5Im21DbR7Qp6xSk6tS/o5FfXLkW+ffmjOKbSdKahoh7dxx/T2U9kLhB/4n9tKpI7wufDxH7YS9G+dYQZA= X-Received: by 2002:a17:907:d2d3:b0:a7a:8bf9:a6e8 with SMTP id a640c23a62f3a-a8366d5bcf8mr350627066b.35.1723681391168; Wed, 14 Aug 2024 17:23:11 -0700 (PDT) MIME-Version: 1.0 References: <20240813215358.2259750-1-shakeel.butt@linux.dev> <5psrsuvzabh2gwj7lmf6p2swgw4d4svi2zqr4p6bmmfjodspcw@fexbskbtchs7> In-Reply-To: From: Yosry Ahmed Date: Wed, 14 Aug 2024 17:22:33 -0700 Message-ID: Subject: Re: [PATCH v2] memcg: use ratelimited stats flush in the reclaim To: Nhat Pham Cc: Shakeel Butt , Jesper Dangaard Brouer , Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Yu Zhao , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Meta kernel team , cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 726FF2000D X-Stat-Signature: byidxtpr4ydq4bxps9eqy3n539rr4qn4 X-HE-Tag: 1723681393-529601 X-HE-Meta: U2FsdGVkX1+1GuNQsTMG+jJvphCtYTsW+xc06iD/ct3a7mWV/4d1QuaUWUvbGm7PEjxTdApDqk9VJ/FMNXg6YUuxv11Rq2sZjdblEgECji6kyVDR1k9lYyZkf373fHvofWp0IgbcBoA5JH1y7nDhkUk/RNv8APctTNdWm6HwHPRk2C0dwGurXHhTGCK6W12OyUb6yabG1fDJ2hgV4rP9V+pbjEThQ5ub0hlAk9Q8D83R0EBfcw3m7Gue0WVLgEc9PV/n+xby9IQ222z5JCveFlTVsN2gfONckj7BKYypLL/xCpzAoMYeTAa2xIgCVaeKt09Qjcb13KTiwQTgMpGs96i2dqlNu3vN7fSATqdJ4K/zlXkA3AN9kj3zXLp4ivJrrYt/WK5FrT2wSZ4DhGXffi+5KwjflwNdkpHArkcV7Z4QOdwXMZh99EjpA+Gd5RUHdJ/IoAAZWbNsm6GY3ourkQpyQ/7MNEJYWPxUpj54YoCHAdP++mG1s9bIDOMzkx9WMajLJy42m9m0NocGK0Ey+7CqnEF9P8uqgkFWTok+SV8eDXI1PFFzuqDcIPxRVwFdIwTSagSFJ0miplFoqXYVcMJwUfhDgOB9L9033R8EK4GTv1NTQxcY6426Ky7qnO+cNk8at6hAL3FtRYTZprs2l8lzTDHUoLtrzTXUE2Td614m1gk2Cr9CHR5tp9i2dhQNoaFTjuuuI4bmPTuDRZatuzcapEcAgX3VErlnjqX2/GLL+0dTIrYeewK/j4X0y9HiVBPkqZMaXT5AGOKk4kI3+sKfU8aJ+Je3Z2OaDKUdhsERhTEZ14P64uUbe4leEhyeLdcpvVRbnqeV51oW7FH/wKpTQC7UmotOGxn8rY9jE69+l7KbBvcVEM8XHb+cps3SlHHiYQc9w2tjoP40/aCITDjeoWHYRcJjdcfqzQKBKgbZmIRbXeL6+TCdEmgy5GUYgiDA+WXQNdykXZp5H3D rMb8sfdE gDSYH3Q6hXRb4NEqC/27azrTxgGih51UHhkZaoWaNK7yfOtLbf865hKsXnCuC0VbA4FDUBKRz66b82g34OuTQB6YGy20UAHaj+k5uwkJs1ltQM1n5Vt2pyJLvI+pQ64lXf8RMu6LM2OKxjt3Hd+Wm+EnFCxwu9hzp8c6uCBL03dj31jT3sqyjYz+uQsM9ZpFX7VLlFgQUZ0kvvBhG3TsNd85VYg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000019, 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 Wed, Aug 14, 2024 at 5:19=E2=80=AFPM Nhat Pham wrote= : > > On Wed, Aug 14, 2024 at 4:49=E2=80=AFPM Yosry Ahmed wrote: > > > > > > We can also use such atomic counters in obj_cgroup_may_zswap() and > > eliminate the rstat flush there as well. Same for zswap_current_read() > > probably. > > zswap/zswapped are subtree-cumulative counters. Would that be a problem? For obj_cgroup_may_zswap() we iterate the parents anyway, so I think it should be fine. We will also iterate the nodes on each level, but this is usually a small number and is probably cheaper than an rstat flush (but I can easily be wrong). For zswap_current_read() we need to iterate the children, not the parents. At this point the rstat flush is probably much better, so we can leave this one alone. It's a userspace read anyway, so it shouldn't be causing problems. > > > > > Most in-kernel flushers really only need a few stats, so I am > > wondering if it's better to incrementally move these ones outside of > > the rstat framework and completely eliminate in-kernel flushers. For > > instance, MGLRU does not require the flush that reclaim does as > > Shakeel pointed out. > > > > This will solve so many scalability problems that all of us have > > observed at some point or another and tried to optimize. I believe > > using rstat for userspace reads was the original intention anyway. > > But yeah, the fewer in-kernel flushers we have, the fewer > scalability/lock contention issues there will be. Not an expert in > this area, but sounds like a worthwhile direction to pursue.