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 6D368EB64D9 for ; Mon, 10 Jul 2023 09:35:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 03AC66B0075; Mon, 10 Jul 2023 05:35:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F2BC26B0078; Mon, 10 Jul 2023 05:35:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF2196B007B; Mon, 10 Jul 2023 05:35:23 -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 CB81E6B0075 for ; Mon, 10 Jul 2023 05:35:23 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8DCE31202E4 for ; Mon, 10 Jul 2023 09:35:23 +0000 (UTC) X-FDA: 80995194126.03.B18E4AF Received: from mail-oa1-f49.google.com (mail-oa1-f49.google.com [209.85.160.49]) by imf19.hostedemail.com (Postfix) with ESMTP id 84B131A0004 for ; Mon, 10 Jul 2023 09:35:20 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=iimXhKYp; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf19.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.160.49 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688981721; 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=n8cUDQW2Wt1AG6yqZ6YmxY8FJixhGQFCyAPOkkh57CY=; b=UjCp1jNc4TbUx0LqyDBjrkvSTImwd1evuthtW6OV5FSypxdMy9JsqW0r4QI7xvIffgA+NK +1RUpu48Fpwkz/I9bdpIqsap8pxgOjoADhxqh5PTKJhcM64pe3d3klRiqM/o+kjlje0sLt zAfb+qIg59Z7vQmz8HkuzhDqilrG+YU= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=iimXhKYp; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf19.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.160.49 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688981721; a=rsa-sha256; cv=none; b=yYigUIj+8smM7AdAVze8ootQkBosTxvmnOe0MZuqtFPXrxSEiOz5NETyyUn8OsZWtVUkm1 FFssq3ORc7dCPautJnS/OAo43/5tiBwG7J7PHGzYWprklT+JL5JwcoUwF89ksY7NnoguOE X4ZTSl1UDdFq5oOa8Al6inIUosrK7hY= Received: by mail-oa1-f49.google.com with SMTP id 586e51a60fabf-1b3ff2460ecso3731997fac.0 for ; Mon, 10 Jul 2023 02:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1688981719; x=1691573719; 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=n8cUDQW2Wt1AG6yqZ6YmxY8FJixhGQFCyAPOkkh57CY=; b=iimXhKYpBw1g4ac9eGc3nJen/n2A8NgPXrXgsxRPJ1RlsxtNZnuwgxZUE77/6K1AnE crPiCiKpc+kq7i9me7Wkh/ZJe3+qh8sRUVHsLMDjS8Z3xYixN7DXf8q2OINo5ZqhhRQj 4b/nkAHMYm1uhsYLY8b13HBvYGEz9LlwnKEZaUm+nMTH4pTjrYv/CUSFtTqNb/TXWbSO GTZKUoSZVVe3axHra6Nc62xEtGzUKg2NByK9iR+4mHtTH4brQmDv8CA9ErLj1atGz5oE i8ePuuNa1f6hqn1i8qVFG2Lcsq+jAwyQSMNrIB1IpkhsV3Ong7I2Cbv6SMRB2+J248Vp j8Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688981719; x=1691573719; 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=n8cUDQW2Wt1AG6yqZ6YmxY8FJixhGQFCyAPOkkh57CY=; b=g7OifOq8LPh+leKWLNUG0okAuHjLGnxn+bIehc7JrfVmqoYMfAchJ/61omIwrOflm4 5fYWDODuzI46PXZyDhfrWJA97IDScr55t3MWeCTaQIbFIuxnLkGZeAjdR9sMwBE1Li9V NsiZpkjnUyhO9Vy7RNZc6alAvErQYHOsUF8q4FzocuSzINd8TeXx7YDN9L3UEPntFkzo CuX/NiT3NthXl4zckYhUgzH2r787nleRs9artPC9Jiu7wOb9g9T3B1QGZP63v5WzmvgO zaIzEtSCvXwVdmsuWdXzaEKgr6wNowiw9BbNUSlkLqMCk6DPLquR9LOn+DEWw/rLkysq 5v5A== X-Gm-Message-State: ABy/qLYHa9FJ/XMek+TAYv1Sf4TLmL66xghhR0e9RKO4z7IG9zYQarUE 0cdBqezZba6J/VzvTOYIAHiuLWYveNau+hjBgYKMkA== X-Google-Smtp-Source: APBJJlFZzbtC7/v1I7GTIc4+TZebDO8Lr48zWJyhMe8yA6b+HTXCxfG2DzUvXdRDA3Z/fDA1RMQ3dI3OvYdQRJ43e64= X-Received: by 2002:a05:6870:f698:b0:1b0:3a5a:4039 with SMTP id el24-20020a056870f69800b001b03a5a4039mr11287379oab.56.1688981719290; Mon, 10 Jul 2023 02:35:19 -0700 (PDT) MIME-Version: 1.0 References: <20230707044613.1169103-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: =?UTF-8?B?6LS65Lit5Z2k?= Date: Mon, 10 Jul 2023 17:35:07 +0800 Message-ID: Subject: Re: [External] Re: [RFC PATCH 0/2] zram: objects charge to mem_cgroup To: Michal Hocko Cc: minchan@kernel.org, senozhatsky@chromium.org, david@redhat.com, yosryahmed@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 84B131A0004 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: acm5nwti7oks8ue5ejactdmanzimbj5q X-HE-Tag: 1688981720-980095 X-HE-Meta: U2FsdGVkX1/fi/YTZNhGDSKsGoodf21Sot5BNZIfmwzfay1GMfdXuEJcoVnyWpUY1jTs1/QVrSVrtcNdlFjbVOwyvZsmQ172oaFrR1wRngLQwnQEnkAYKUtFvOeWUmNflvGxZEObEnGLnxXhGoNE6oXI0NtrXgiiwMLpz0MdQVqNrcB12S250SVOCshtB4rrBzHzI0F5qvPVbSEqb823JrN2zf+ODxaK8FpjeaCkZS6ATp+nx8TobhMSdvOpv+25KaYpi6XZwiuw3aR+uEb4bI/AUW5XjhQP8K3rHJrTz3kOZwO5BhHXKA5xCs9d/atSOURoolyx+qi4TsyYCxMm5VUWcF3oFzEttn57LMpz+E7QORzqAaIuFZDU/24vIqwxMEEzx7h6VvZzR3/jRdydyB9GeZBRKu1SLITzn5neU2EoKjG7xumku5ToN8diAOFEXIq7uat3JQN5+DOP15sui/aVFppNP8rexhLstSRYd1WTopcGRySqEPKNPaUDkxkujiIwRePMxI7iCuwF0yCKPNnrZXH6rDog9IlhLsy1qFWLhrb4oYqMQTOrQBTVWZ/kjExGafMz24hsvbX0SwTOd4Dfp2Fo6bhM1lTCNXWiSIbYNFhq0cjOthMGoj1YB1JcIpSGcJCskh8YIzUNOYja1KVay+UzV35HSuiDJcmPMTUXnMdJno7965Ql4SS5b3yyOGomOUb6RedfHEyQ6J0aUT42PmId8Eq4lpG24zGPvUOmyWZM8gJ+x6AodfvgunuU5eYK725QgrXvxlPNMtzhQn97fCzZWT61muzLzWHIPsokaPJTb9kiYT/ltkw8Cn8ZbTvj7m0n3UBaXCbdiT9tXZjSLz3JbLrz0gluy3fUeNzDeFbin/s+wVCDNzSVutjYg7RXXEu1qvC3MNTHvgX8eA+W1GGaMSK6O2xHd5+moeM8fmEkgTTJUF7nOgRBZRzPwHZpOkg+JRICx7dUM9t KFPSJc2V VjpAq+EVqW9IpRV5fC3Ao5bvMxMedYK+umb7xEWH3trRm0cWBCVZcUZ3DO1AYAHR5YJUZID2CXvlGOaPv1unsZwjBdfXv5ferr47Oxq5mWHLCUFnojynhPekRiK7MrnyB37iQKf8oJ+7XunRQ/fQjqFGnBNM2nPNiD0zEPvEJaop2DuWalbNWQRzb93T7736oc0JpzX1oCRsPonuKcTKWVSffSsgDTIZgcyj+bg9Id8I/QxHa+1m66iNGF6WId1bG4d5IfB/f89zIo3gQWCPPrHszp9pcoAw2oH97AmbAD/F9xY2ZtFqaHeixOck2w2/TsBS5TyPK1frq+HKn5eWr8vv3z9b9OWmMcZ9L/WA14IML6lXYq0lnpCax1ywG8pTvw8P0M/KuDBbHs8vhyiJ/P8c87qa++3Vgg7zqj2fsAuMrDRcYc3kTgUTkfOhZYAWbiBi6dH+GUWycz/q/wI17HfLE1CH8FGkAqYjLcrRoz8cyAeE= 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, Jul 7, 2023 at 10:44=E2=80=AFPM Michal Hocko wrot= e: > > Why do we want/need that? Applications can currently escape their cgroup memory containment when zram is enabled regardless of indirect(swapfile) or direct usage(disk) . This patch adds memcg accounting to fix it. Zram and zswap have the same problem=EF=BC=8Cplease refer to the patch corresponding to zswap[1]. [1] https://lore.kernel.org/all/20220510152847.230957-7-hannes@cmpxchg.org/ > > > summarize the previous discussion: > > [1] As I can see, Michal's concern is that the charges are going to fai= l > > and swapout would fail. > > > > The indirect use of zram is in the context of PF_MEMALLOC, so > > the charge must be successful. > > No, this was not my concern. Please read through that more carefully. My > concern was that the hard limit reclaim would fail. PF_MEMALLOC will not > help in that case as this is not a global reclaim path. > Sorry for my expression. I mean the hard limit reclaim would fail. As i can see, the PF_MEMALLOC is not only used in global reclaim path but the mem_cgroup reclaim. try_charge_memcg try_to_free_mem_cgroup_pages noreclaim_flag =3D memalloc_noreclaim_save(); nr_reclaimed =3D do_try_to_free_pages(zonelist, &sc); memalloc_noreclaim_restore(noreclaim_flag); > Also let's assume you allow swapout charges to succeed similar to > PF_MEMALLOC. That would mean breaching the limit in an unbounded way, > no? > -- Chage compressed page once, mean a page will be freed. the size of compress= ed page is less than or equal to the page to be freed. So not an unbounded way= . > Michal Hocko > SUSE Labs