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 CB5BCC4167B for ; Thu, 30 Nov 2023 00:48:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 615A68D0027; Wed, 29 Nov 2023 19:48:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C53A8D0001; Wed, 29 Nov 2023 19:48:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 466268D0027; Wed, 29 Nov 2023 19:48:01 -0500 (EST) 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 361FC8D0001 for ; Wed, 29 Nov 2023 19:48:01 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 095198065E for ; Thu, 30 Nov 2023 00:48:01 +0000 (UTC) X-FDA: 81512783562.17.2DC8E73 Received: from mail-oa1-f50.google.com (mail-oa1-f50.google.com [209.85.160.50]) by imf06.hostedemail.com (Postfix) with ESMTP id 5231D18000A for ; Thu, 30 Nov 2023 00:47:59 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RZX7HGPx; spf=pass (imf06.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.160.50 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701305279; 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=px7lu5nOqajxdLEanLNBtXA+0BLm4pP2tpUPChWnjUo=; b=BJwbhv3KknLvFIHj8RNA5Q4nj7E09aD93SI8Mc+ReT8ML/mtDA+AgB+gohcI1plGLcZ0Yz AcTU+C+UCE7AgMxoT7TNSFMwywlbpNGBJlfHx8lAYbgxjQ8uagD6JlrwrOoatocVw/5RU3 mAMQZt4Pu+vbT/QR4uhdm+fklgZMmRA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701305279; a=rsa-sha256; cv=none; b=yT8F44lXadqugx5MxUz2fKAdtwN30H/zYSGSVJUA+0FZ5TTbuAXqrOjR3+LB2knzHFeJPZ A+G75u3+x9WCZ1m/hS8zBrnokH3w69I7dUK61ojzWPwccKMmgq9yYv3Dl2R+i9tZPUrzQF /gcW5oPodPHRlb6QheKGAcHbl1p3+/M= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RZX7HGPx; spf=pass (imf06.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.160.50 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-1f03d9ad89fso175474fac.1 for ; Wed, 29 Nov 2023 16:47:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701305278; x=1701910078; 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=px7lu5nOqajxdLEanLNBtXA+0BLm4pP2tpUPChWnjUo=; b=RZX7HGPxkodWtvE7/UQhNo1icVQH+FMmmQi/T+Uf8wdaFtYj5xSdvq5Xz0pfT9JOV5 CWhL4jfphYPaHp8L3JOzrV1vmnirI5R6z4PJcNXKmVTJMv1XvaPVLalU2WZ2gVKEmRaK R1bCVHSx6JSpWhqAT4xcFDeZ9lhBErL7L+cDdkhVKeq8eaBw4YguxZ/jFA1iY68TCiE/ d67l8rh2IIq3bs+DVSekr5OFKJJOis/xALFbgC4QFal1y+Mi+i+R4oy1nf3MUCDa4Z1a 1z0G6LMWb2/aRwq2VaNrUrbwmDuy4gUQqmL6zjkFequLCORdLsZL8IWtOYSZFukx5YXz zH+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701305278; x=1701910078; 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=px7lu5nOqajxdLEanLNBtXA+0BLm4pP2tpUPChWnjUo=; b=uneu/YriU1zQtnBhh0xmaITkzLJalzXlcj/sUVRmi4WcnQMwPhtR1uvYcxOf0nfIXi 9yShRJ1GhAMBtRaVWn7R+X1kjw66s2JWOZsVCcuyu6/EnjDktU2A0eL28j/dgPIrGORc GpIDh3PdwFMe+tw8aPL9C3kNFzlxBPiMvTcdPOt4ho+sHScoW76xf2cindEl+GBotr2k V/SDURsWXmtvH8zUfrIOqyE2fW7aTIPsYhbkpB8QoA+qVrSrH2hWlporfwVl7E/ogZnu h9BodMrgwDLhZ+cEozHQvx4QyzniWoQHv9veZKxEQD5X8DRmpqStII88DtZfa/NgjY/O X02Q== X-Gm-Message-State: AOJu0YzGpAbiktIZGNRSicQSJJZxnaiRQ/ZxUV2gcy5V4tHcej8aH5p8 uTi+Ny6ELMeHULJfd3SCHGziqsoXBet43X+Ua3E= X-Google-Smtp-Source: AGHT+IHNybKJyRL115STmke+mJBBLpb72k/nusUuGsqlLJZZnSa/+eziMVVFWzCKHCT3Qez7vepBVUhLO2cGnfNCpUg= X-Received: by 2002:a05:6870:eca2:b0:1f9:5081:f287 with SMTP id eo34-20020a056870eca200b001f95081f287mr26311523oab.27.1701305278396; Wed, 29 Nov 2023 16:47:58 -0800 (PST) MIME-Version: 1.0 References: <20231127193703.1980089-1-nphamcs@gmail.com> <20231127193703.1980089-3-nphamcs@gmail.com> In-Reply-To: From: Nhat Pham Date: Wed, 29 Nov 2023 16:47:47 -0800 Message-ID: Subject: Re: [PATCH v6 2/6] memcontrol: allows mem_cgroup_iter() to check for onlineness To: Michal Hocko Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, cerasuolodomenico@gmail.com, yosryahmed@google.com, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, chrisl@kernel.org, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, shuah@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5231D18000A X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: f4pdzz6zg7yyrtbrf7i7qszaq3scdgpf X-HE-Tag: 1701305279-363325 X-HE-Meta: U2FsdGVkX190x114l+EISM5NLkRYgr0PRYGHr1n3jmOlbZDhIIUrcTuYzgbyl9/9mUAZ2ZtHuDpM8V8wsLmC2Bv09phmj7wIjV1N+4KQJjujSyIiIKpsP2tCuF9JJTxy5CB+OFkA+dlpp8P7zHiLndf1bj5vWf20tjMGg5OwGxBHgoQRZ8Ebe32E8qALcoxRMtBoo5QAmMEs10YRbUtSVywpu7pQ3WJEWdOQSvjxuk59Sg1S7lD3tuwY1b/O1m/YtyIIvJCK7x4L5BVUP6AZVh/ZIoihFY7qCpRDUocPymWpmGl2Ax2l4ypycMtHJYavgYxg5fWZwkK6i9HcovbKvakAzk62rXYwqwSxJsCIF6h1FYAkR41sWEMD9q52RnHRhRLSNtTsylb5D20QIOc2lymFssMq08g6JCgBn1wFX4lb2vcvsSEdfJ92SjhHNpybSVEE/4VQZqVWsmfa1X8eqmwudz0+Kib1p6YWxLjBJaAT/eTpR+p5o2gi0zG0WR6wGZS6OIKpaQANOwMTB1+GDhbpT/OAXZmfNYiV5Km7rUo85ZHD1B1n8jXVVqT7ldZhwcRNWH9imB+AeU4uAN4+J3UiFzrGTbZjNOUTar4Zs/viIXMruh53UAt4ajVpQ0NM6wtgYW0ycVoWaCX9SwYl+8GmYsd0zNxLLuh+t8iJZUBowkgMNo77rBEeftXRpEoTAyzQ7IPMvpkJ/R7XeS0AZ6dSX6sdBGqm0umNqBbqdgx4xNBuJta9vwMJXA7N44pTLyhcbfS8sCqHEtxQm2SJQctIaOce5dvNMyPIqHk9EGnwmuQYuW9r8icc5TLh3X2f6Le5J57tBM2XfFymkYFSCB2bHSWNB9up5jVJfSWx0KJ9oLtSGQa6l+49aUnhFbIHzrEJZbEqXR/vtoqtKqM77zFdwn6q7VfkVXVgzZ7RWR0NEkDA76HJCmAxG64rMdXA/oWRXPz+9//xK9VO3aS a4OZYvso p7TkkLDgYzvlaYSBMpO7aE+XEAWiQeleyqTnQpnJnQoSmU+iWBmEmdAO31DQp9I+02UKn5MOevwxNTrtDMjWpozUjMHHfQGaXVbzUR2TsnD46RcnSrFN8r2+MeIs9hdnFw4LTxubHUIVqJzD85bg1RCQHAZd5yeicA2hX0L7Rd7x/LqZ0ILxfVTg8zzILxGma3K9o8Ino+Y/esl0GZk63rTU26DhbTpKVudLyw+f7Cu+RoSoY4EcMCfPvqJez1JVQ1t3c7lUCk+D+1T7+52QhESXVY67rzVhKnz/4HJujJWUUYZR9oxfHHSPBWJJ1DBbRPbbv9CwmnAv2majEqEspN9jpFhxZrkqzXEMe7HOTvCRtUGqVcOAS7H7wlR3S3CPCyGLa0zUxpta2zjOU3YG0TRmb98Mb5aiWOuIsfsB9DTH75nZRTWxJlihnB9WnDFbqWHsDZnR+7TAzA4jsvxVxIir1uA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.003582, 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, Nov 29, 2023 at 1:18=E2=80=AFAM Michal Hocko wrot= e: > > On Tue 28-11-23 08:53:56, Nhat Pham wrote: > > On Tue, Nov 28, 2023 at 1:38=E2=80=AFAM Michal Hocko = wrote: > > > > > > On Mon 27-11-23 11:36:59, Nhat Pham wrote: > > > > The new zswap writeback scheme requires an online-only memcg hierar= chy > > > > traversal. Add a new parameter to mem_cgroup_iter() to check for > > > > onlineness before returning. > > > > > > Why is this needed? > > > > For context, in patch 3 of this series, Domenico and I are adding > > cgroup-aware LRU to zswap, so that we can perform workload-specific > > zswap writeback. When the reclaim happens due to the global zswap > > limit being hit, a cgroup is selected by the mem_cgroup_iter(), and > > the last one selected is saved in the zswap pool (so that the > > iteration can follow from there next time the limit is hit). > > > > However, one problem with this scheme is we will be pinning the > > reference to that saved memcg until the next global reclaim attempt, > > which could prevent it from being killed for quite some time after it > > has been offlined. Johannes, Yosry, and I discussed a couple of > > approaches for a while, and decided to add a callback that would > > release the reference held by the zswap pool when the memcg is > > offlined, and the zswap pool will obtain the reference to the next > > online memcg in the traversal (or at least one that has not had the > > zswap-memcg-release-callback run on it yet). > > This should be a part of the changelog along with an explanation why > this cannot be handled on the caller level? You have a pin on the memcg, > you can check it is online and scratch it if not, right? Why do we need > to make a rather convoluted iterator interface more complex when most > users simply do not require that? Ah that's a good point. Hmm then I'll just do an extra online check in the zswap reclaim callsite - cleaner and less invasive. Thanks for the suggestion! > > -- > Michal Hocko > SUSE Labs