From patchwork Fri Aug 4 07:57:20 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhongkun He X-Patchwork-Id: 13341436 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 2376FC001DE for ; Fri, 4 Aug 2023 07:57:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E3118D000F; Fri, 4 Aug 2023 03:57:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 793868D0002; Fri, 4 Aug 2023 03:57:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65B1A8D000F; Fri, 4 Aug 2023 03:57:36 -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 575118D0002 for ; Fri, 4 Aug 2023 03:57:36 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 06639140863 for ; Fri, 4 Aug 2023 07:57:35 +0000 (UTC) X-FDA: 81085667712.28.A85ACEA Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by imf20.hostedemail.com (Postfix) with ESMTP id 866551C0021 for ; Fri, 4 Aug 2023 07:57:33 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=PPDqJV2p; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf20.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=1691135854; 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=rG4+kOpeg7A78jhutmi+pmLSeK2TMW5Crpxh1v3NLCg=; b=CYsQNkjulju4aEl8M2Ov/hEAr562z5rN4m/Xy8Gs235edX4xh1PjyeiX9ClCOUZRs+tK1X 74Vpk+Xxnja57ZB3u9iG6QywZKmYXRxu7CsL0t4/0ME50CETa1dXFm4SctA+75pTVtsZEm 3BY1GfAI5CZu57HvauiG+DHKaAEDbvc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=PPDqJV2p; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf20.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=1691135854; a=rsa-sha256; cv=none; b=ZKsHZIozKgKx8GcRH33B/tR1TqMxYoTjbi1InpATrojw2A4pwKtiaUS4Uj5y+8Nm2fOxZ8 RjB60tyIAhBCXwj0sqQaJuk+QRea16SQ7hIyHa+acWgXa3Mdu2lm1KXJTnnTYGANqSzCwX Odu1Fc+IYO9FECkU5p3VkLIMRS40SxU= Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-686f8614ce5so1694093b3a.3 for ; Fri, 04 Aug 2023 00:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1691135852; x=1691740652; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=rG4+kOpeg7A78jhutmi+pmLSeK2TMW5Crpxh1v3NLCg=; b=PPDqJV2pkFNJHNQaw3+BhtMGjHyrERQm5XAh5t0a5vWBqtdpVhLn3oHVBXPLf4Mnyn vEe7DWeUU1qceoplDuR9I1bCscMs+2qhw7dOR4oNxlza+ZIPx/bofBdkR6HlsD+UvLsO qLsxlP/Qg3XH6Lrfyq08v8VddcQLDaSbYoNDvuhdQNE8jy75soPp08ctNZ2k94L95pET kzsalaBbJmlFlzZ8OqymsWR2lrx2e40NkZYAXYWaTbcdFx86P8t6Bwg90U8sXZvBjQB/ RXY9DkxMcN2MnGm+m9tNwk5D5GFNaJ4mwwWG3yMgQk75uYg4mhfW1BeaRITDUHT7v0lT UV2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691135852; x=1691740652; 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=rG4+kOpeg7A78jhutmi+pmLSeK2TMW5Crpxh1v3NLCg=; b=OZG/BGPTvf0+xuhkdPZK3z+RAY35l74rLZ1feaybiDn5vKpeYEFjcF+lgFhPjozPh7 y7nyG6iYfBDuyUhq4jQqN+O1eMlR5u9MP2MFccC+QOkcw3jnu6nc4hIyhzY4aeZd+F8P fpxiUGL3wHvS8am31ezXoToim6WqvBa5rjDCERR3eeFvAT9WT1G2pEXPCdJVMKRhm4t0 Jz6ONa+HEoVuepqh1QF1bW3IfNWto1ybiSmJVKDblXfCehPR3u5bYuPiPq3TcyEzPxjQ Qhf4XHYvoGcSpLPsizkPMTWpMjOwI4Atn+OhaGy10UP3f0S73iCiwkyqd05//aT/XWMP 9bIw== X-Gm-Message-State: AOJu0YwkDQrd80gCEnv8SWTOpaYEQssFpL2Yxk7IaZGoyhlJCdaZ+aRp ZFu35vqeRpEw9pk1RctbUULm5w== X-Google-Smtp-Source: AGHT+IEt7HGaPrPteBwIU1n3ZevOva5VIISA2YP7MmTzWbf+MJj9gTQGy9uSwIeKmudb+/ofm4T4wg== X-Received: by 2002:a05:6a21:6d88:b0:13f:68fd:6ae8 with SMTP id wl8-20020a056a216d8800b0013f68fd6ae8mr1357604pzb.57.1691135852009; Fri, 04 Aug 2023 00:57:32 -0700 (PDT) Received: from Tower.bytedance.net ([203.208.167.146]) by smtp.gmail.com with ESMTPSA id p26-20020a62ab1a000000b006871fdde2c7sm1008676pff.110.2023.08.04.00.57.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Aug 2023 00:57:31 -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 RESEND v2 0/2] zram: memcg accounting Date: Fri, 4 Aug 2023 15:57:20 +0800 Message-Id: <20230804075720.207943-1-hezhongkun.hzk@bytedance.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 866551C0021 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: t9ksq5mdu6zo3midu6jp6qsojtsrhtnb X-HE-Tag: 1691135853-190970 X-HE-Meta: U2FsdGVkX1/WdxlGXgBGRTLVvEaTDjP6V816vrM6iYlp2XZoLehq49n6cbcNFD6uVm1oO0qGtUw3fFVAiGtOvZROcyVZLWXsDQZC5r3HkkzUkLNSxhdtRMl5uMomDRE6p0oLH0hh7/jKH1X/njh32OuVU16x8epkmwBk7RCQUihX4Yagel5VI9Llp6dd7dYmlbaMojUhEbghabeim9vCXzzM8pr1hQ5gQIFfOIDvRnODDScxGJMlETXHeHhlQn9QdTkVFpX1h6a0LVCfuGrh+Owu4SQyljSH/Na/tAgtnVaYbsqs11D3yxNs9UeI5uXQnWFqYk7XhxQsytW2Ze9v1FdcbhdLmheHPCaPWQEUfa4xrnVTGkJHYyl9Ahxw7vJYRs50po0Vx9Rg7L1r8x+U29WL1WA8Xhhgn47dR+gYMZXPFtJR85pOHFSpIIu6ea5i6ryWpKSHZcsnE1q0YFlbyUm0szqUeJM2L79Yaw/NzpSgIu4QFZ90ZlqRKh/aIYLc6XLtawcSpJqFV8ZRXYfEG4NzXe2ajXgdOMw8F+ZL8uznNgpOOfsnE4vW1DFG+b2/m/5UVRyc8sofrMRYHKV4sMRObx3VQ8L3NGecxvtnOi+fz8uj8w4+jxqDV8M9n5pzgh+S+P4FNNBJJm+MAPWpO54lYyUsye8sq0bA1o0n2fyEG+h4slIYg24RRBew0PvoT425w140KQDXm1yXBfRDC/IJRjoZC4Jgup8u6qLJ+XjglhzzkKqSSXZK3dXA5za3ow/GGyE8mlH5mBJR/Ob/TS+8bhaVZD4jD50AGfeJOsND9HiFzYEagtXviNVQD3/WLda/iQGqQ5m0n5798h7iNEP/zEWvztuX8X5CSPHt2fDUGXSgHE4MG6/S/w6xdMoSoOltKskg7j/y/zpMzzlKlyVFxjN52GH3hM9XMnx4zcGuAdXsRJLXNG3Md8C/UI3QEXl8VhGbywLXfCQiP/y Ff9S4PdT fxk/tFFfahRHlzDtOhEIorFxTTwV4zNrZVNYdHJNjgVKXRDmxxLbI2R+OsgpR0yePrhIj7h7mq9gXOsk6Y/NRXUfRZuSG6TFYCuT5kGPZZycS8ZUPRiX3lPzP4xdvp8kDPlIhCI9jhL60vWngGeLJhY4ttAh1LFIVoeLKPsWSaiQIsnzZfT1S0Ua8XzuABkAFJFoVtSiCDHqCSQTgP/n3UCF2HvARH0Ey/e5s30FMR1MQQ2E2uVqCt9MJZOC9OEIBbTR8enOpuejUJEZU8j44CL0JvQ2d2DdkqLjty+ZlMD/tjaVY2PauZ0uh+qFyG59sv3ii8Gm4psL5OIVFnEl2Zps/KY7TH+BqzjhRisQZ1m+FOh+mgBjD9vGpF02zBN6cfXiNlHNAd1j+sCGFVXnuIbgkzRMv1MPydf6y527/tMJNro5SovfJ6zqYk2HKEY58zhyJlx5lKfChmboGMwF+g38H0V8xr/O1oRw4 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 | 45 +++++++++++++++++++++++++++++++++++ drivers/block/zram/zram_drv.h | 1 + include/linux/memcontrol.h | 12 ++++++++++ mm/memcontrol.c | 24 +++++++++++++++++++ 4 files changed, 82 insertions(+)