From patchwork Mon Jul 24 06:21:43 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhongkun He X-Patchwork-Id: 13323467 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 05F08C001DE for ; Mon, 24 Jul 2023 06:21:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 61B306B0074; Mon, 24 Jul 2023 02:21:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5CB458D0002; Mon, 24 Jul 2023 02:21:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 493796B0078; Mon, 24 Jul 2023 02:21:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 347796B0074 for ; Mon, 24 Jul 2023 02:21:59 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id ECA6EA04B3 for ; Mon, 24 Jul 2023 06:21:58 +0000 (UTC) X-FDA: 81045509916.25.F90F64A Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by imf15.hostedemail.com (Postfix) with ESMTP id 4F115A0003 for ; Mon, 24 Jul 2023 06:21:56 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b="TGImT1/F"; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf15.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.210.180 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=1690179717; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=vEgIOhnjJFOuBfQSwGjfY7uJsZuGLdD13XcGGvP6YGY=; b=xTpwdQ7Pngs5uX2vARpyiz6Y+JHnlTK9nCskFVIPcjqrNY3yTgn2g+OgVfKUcVXVvdeawx l03ovEuGpUHYh2X2XVgBINMqCb8ry899DdamM5FpkshfJT/+yt01Lwo/yKlOzO7rimux79 edHKrNMWo+7LV3k/owuN/0DVjAF+9CU= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b="TGImT1/F"; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf15.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.210.180 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690179717; a=rsa-sha256; cv=none; b=I3R1sJH3orhqDjdH3DlGRPTBCka9EHP5g3zxww4xJjdymijQ5UIMMYWlLgErg97oguzziq zMYVUHU19R8X8vBSudWwL3yaid/YAzkrBfEVpXXEVQkem8P+T4ASbXTtq3VKzF2P7X0nbG uzA80TSZ5IydIULDkFj8nv3cCxsnqXs= Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-666e6541c98so3828653b3a.2 for ; Sun, 23 Jul 2023 23:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1690179715; x=1690784515; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=vEgIOhnjJFOuBfQSwGjfY7uJsZuGLdD13XcGGvP6YGY=; b=TGImT1/FEN8ssaeZsj5As+U+pYXzZkFsvYR6F/1xLsVUaLXRgB4YiibaRYVLDtuPV1 LspiIu4xLdv1T99qiDkdaftxbVLkqAC1lRdxeQ3zR+ZdO+KIhFz/cSvq2xGa0KNxnh3h TvehrRCiXi1bzj2z+ANM6MRjZ/fogxByHruxpvsx7r4wj8IIhmLXVsOWllLhaRWTEri3 tGcjMhTOC44Oj/FnoCQGtG4QGvIh9D63sMdtdDS0NNd4LJagUdfOP3PlOXpJMfMDNlHB fU+k4VSpGW3+94wS1MRRq5UH7yLB8whf/iI7khCb6yStg5B6HcCbW6JLkKcUnQBhgaRI JlTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690179715; x=1690784515; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vEgIOhnjJFOuBfQSwGjfY7uJsZuGLdD13XcGGvP6YGY=; b=ddRWS7XrkDSTr3RrLyofBwZ2aIWGa1JfWP/e/7UB5aRVrulLqLK0PMWhS1hvAKuuZB ri6g2FmMxYRcmniSlgEILogo2PCthlqXlDMQIZNnuxWs3FD33b24EQ76NyIQMcdnbiCc 1vmKVhYaFBu0GIGlA1Pdw4qlkS9k8H3pQrPlIKWrcrEZaVX3WDbNVJ+YutOpj8rrUdkJ I3ec5AROKtuEDRPa6jmMsyIOVp/vcKfA5CrCkv/l0RNBE1Q0cA0X99G2NYVitZRPkeae yWxwpX88l8AnAp2etrS6M1fDuPErxA0NQrq7aux7yVTPYwxbTH1P2hNKDV+b977tO1Zw dqGg== X-Gm-Message-State: ABy/qLalE4xuRXYleCLaAZuxo//nsYioFRHLpZg6Ts3Lq7pU9BStxPJA 2LIRCJI5wDrVlpp97GRZw+8OFg== X-Google-Smtp-Source: APBJJlHBHTU5/ig0tcLlK9MobubjQ2/sxG12roeHPbT21t2WE8xxD7ylwRH3L9uP3q/CvO84nFxSxA== X-Received: by 2002:a05:6a20:3207:b0:130:f6bc:9146 with SMTP id hl7-20020a056a20320700b00130f6bc9146mr9930949pzc.14.1690179714940; Sun, 23 Jul 2023 23:21:54 -0700 (PDT) Received: from Tower.bytedance.net ([203.208.167.146]) by smtp.gmail.com with ESMTPSA id p26-20020aa7861a000000b006758ae3952bsm6833336pfn.122.2023.07.23.23.21.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Jul 2023 23:21:54 -0700 (PDT) From: Zhongkun He To: minchan@kernel.org, senozhatsky@chromium.org, mhocko@suse.com Cc: david@redhat.com, yosryahmed@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zhongkun He Subject: [RFC PATCH v2 0/2] zram: memcg accounting Date: Mon, 24 Jul 2023 14:21:43 +0800 Message-Id: <20230724062143.2244078-1-hezhongkun.hzk@bytedance.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 4F115A0003 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 4b9mjqjkbqdz3eengybio4phdao8cfag X-HE-Tag: 1690179716-88499 X-HE-Meta: U2FsdGVkX1+4Q9pHRKBNhMZHxuVe28mJ+yqgdULHzLX1znO2IQeWaWB7jVRWZ5PZa9wSeVadGWwgePXR57n0bTrgB9gDMEZKb73dBJHrJtJiEV+RYQFCIJOd+vhlU+l/b7u5gss2SJdc92J3G8gQ7nhBHLdmwjLbrU+/HALFuFnjgoje9IeFQAeLoosfjfyWsD2J29qHF7WE4n4NyXeXUJ0xIu+r526IWIM8HB2LC/vckopaPFExx+Pk86WhvKFoO+sacGs7bLEai1lsUwC/x7dpMZQwFvShfcPhkD64S3Ok70hLWZ/s9I5vX1MS6IslIzhelGjhYNg98QIxZ4LR5oM01udf7oHkevD4rNNNgdodJCLQASGaA5AaGHcL95rP0/ggj6syI06qoZulgFeM0vaVD8yyZrHgTm2/x7u4Pqz3uaNjFHbFffKRJoEI9FVy63OPMcmxXED62xaToSRncHCfpPTIO6xapabW8+/IiTMdcHmDtd51APr1AKBVM4A9xs66xb24eJCIvwzrSAWZQLhMzCdE1F+fMimOMc8MAdLMkpBplo5pBtvhFRn3Rdqe8TJc1c5dgpBpGknNUdHyKkc3JkpFlNtD8nLxNxPitcZWNsxglipPYLnd6b2HleKutblxgqwm7eCduTuAeXXn3WtdQgaf1ZBXjXFR2eshtJr4refPG+IuWqQDmQGCntaA3WgHmDygPnj2oArYjPfxZWS94ce9M4LCqrJijfDSLjqoD8TcLKwH044FJqe1FAfKxUMb4MUKBW0KtPK8GoprZeYXXb2MyZjU8goUeSQ5T0l2b9WGb7mUd4QhNRE3BNf+hvuGnSbdZsQb9OpZ0bykCRKN44sQArg9fKf0z2apiWBCkdcYyFRPFBkSM5LRkoSlpz1GDPOMSfWjRZc5UcpBTm8ocVLUVvS1YOMQAfLkKFWh9urTtdyWCqpAQb2kHtAuzWU/iQV/3GTBdhM9MTJ EVbL+GxU LKxpPEzPxbxa+55hPetgNi0vlhFo7/rYQGUgjWAGJjepHdMhhyUfXUJehYiyTm0Sb+qYswcGHHixPmqvu7cYpv+nD3VZo2vsqA43pz7iP0IWFtnzzcLWsU8kXrI6XAQlTtVflRpMvPR0lbOfyC1NrcRlxv1e5Y/6d7Q2hw7QfarkOxvhfTbqjIhbXQ4e7JutpFHM/VzU1oU/JaX226ldnvIOixwo59nr+cnPWiZmsac8e35m+WVrJt138oEHfgm7ANObq8D/lcTVG9oT8dUkfbLrqWGZMSdzBQQ3toHPyVfnLhaBi/sYqYudaYIA+t+fAimW2nkWMURMz1A/gn4o2NW8DqKOrCaunz/uI4KgIEpygYD6Q3MKnHCs1+SC3jqOLVFsTNX+8lID214ugB3Vc/y0lbfiLImwdhdJIlKen6eXS9KWDkOmXob4XTbrqHXVoQ/0Sj0krIfA3xSTgr1piZ54YiNgMhG1+pcOe 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: Applications can currently escape their cgroup memory containment when zram is used. This patchset adds per-cgroup limiting of zram compressed memory to fix it. As we know, zram can be used in two ways, direct and indirect, this patchset can charge memory in both cases. Direct zram usage by process within a cgroup will fail to charge if there is no memory. Indirect zram usage by process within a cgroup via swap in PF_MEMALLOC context, will charge successfully. This allows some limit overrun, but not enough to matter in practice.Charge compressed page once, mean a page will be freed.the size of compressed page is less than or equal to the page to be freed. The numbers of excess depend on the compression ratio only. The maximum amount will not exceed 400KB, and will be smaller than the hard limit finally, So not an unbounded way. Changes from V1: - remove memalloc_noreclaim_save in zram_recompress() - add gfp_t flag in obj_cgroup_charge_zram() V1's link: https://lore.kernel.org/all/20230707044613.1169103-1-hezhongkun.hzk@bytedance.com/ The first patch charged in zsmalloc, now aborted: https://lore.kernel.org/all/20230615034830.1361853-1-hezhongkun.hzk@bytedance.com/ We charge compressed memory directly in the zram module instead of in the zsmalloc module because zsmallc may be used by zswap, zswap objects has been charged once in the zswap module, so zsmallc will double charge. Summarize the previous discussion: [1]Michal's concern is that the hard limit reclaim would fail. Chage compressed page once, mean a page will be freed, so allows some limit overrun not exceed 400KB. [2]David's concern is that if there is a page in the BIO that is not charged,we can not charge the compressed page for the fs->zram and whether the recompress case is charged. As i can see, page caches are alloced by user with cgroup. For the corner case, ZERO_PAGE will not take up space after compression. Besides,the recompress case is charged. Zhongkun He (2): memcg: Add support for zram object charge zram: charge the compressed RAM to the page's memcgroup drivers/block/zram/zram_drv.c | 46 +++++++++++++++++++++++++++++++++++ drivers/block/zram/zram_drv.h | 1 + include/linux/memcontrol.h | 12 +++++++++ mm/memcontrol.c | 24 ++++++++++++++++++ 4 files changed, 83 insertions(+)