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 421A9EB64D7 for ; Fri, 16 Jun 2023 04:41:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4491A6B0074; Fri, 16 Jun 2023 00:41:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F8E76B0075; Fri, 16 Jun 2023 00:41:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E7CD8E0001; Fri, 16 Jun 2023 00:41:07 -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 1FA406B0074 for ; Fri, 16 Jun 2023 00:41:07 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E04E21608E8 for ; Fri, 16 Jun 2023 04:41:06 +0000 (UTC) X-FDA: 80907361332.23.215CE56 Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) by imf27.hostedemail.com (Postfix) with ESMTP id 3DF1540004 for ; Fri, 16 Jun 2023 04:41:04 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=lpW8zNec; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf27.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.173 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=1686890465; 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=hUBNdvZEy5ylqnC9r05Mj1s+Fs0jViK6hGgq08JR7YA=; b=kOIzmCgbRnOcWBPCzSzJ5tWGG8bRVYi4B5BFG602cwp7iKctHfFfsjUI5MotDlDrodfnzK 7fQSf9lnXYBdFv8RXNQQmK7aDLPOVT2+NXBAd/Mp8wyVWhpUDM0/qwjkYCR/ZlMCTWnguc Bf7P0zPjUosh6vgzsIEQDkuu8GzUztQ= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=lpW8zNec; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf27.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.173 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686890465; a=rsa-sha256; cv=none; b=qWuTb7jqscEeMvUQQA7k2gbnWxtPEpKrbuyxDWcPwuykgKKeGgFXEXjO7Zyq4s1DeUbab9 NIdMBKn7Xbm/EVduWCwu8T34xx8Lid7afuAo4JwsXJSRisP3BvN5xW8Bu+Iqarmh581riw zGMLzXO/4uXvUNVM/8Nu+tnGJlkQ4sc= Received: by mail-oi1-f173.google.com with SMTP id 5614622812f47-39ca48cd4c6so319226b6e.0 for ; Thu, 15 Jun 2023 21:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1686890463; x=1689482463; 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=hUBNdvZEy5ylqnC9r05Mj1s+Fs0jViK6hGgq08JR7YA=; b=lpW8zNecrnLvVl3tPQDWSW1JtAHSbSGZ6xyE4n3jYQY96CmC4DPj/Phz3UBE9Lh2bs tacUaFd/1MDJx5J2zv8UULmb6ofCIL+85etXUcxCXG0tn2UUONMos4AEji7ohb19Eef6 ryBA+N1+Mxf8pO7r80m4F6iVyi0tj61X1o4uDFdOLHzWqyMJLtyW7Qdt5ArGMlbv70mL FoH1vO6dSJf7bfacYgoRJMfdRXOLEdQQCKfYR/Arp+pubTeRpN92T2U2iMdsSBGaZu3Y JatGt2zxbQHncKkFDKwExEQ6/EYF3kjpTGqfqLm89XW2Y2Kd8T52W2adj/qjDUlBbi10 X7BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686890463; x=1689482463; 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=hUBNdvZEy5ylqnC9r05Mj1s+Fs0jViK6hGgq08JR7YA=; b=YUTHkjXO/DeMFgbYs0cKHYXd2ZOkbjEG7mqdGNqC6XBqmpwx82XjO2oxRl5KiYTAsH OZKqOG4kcj/FPjuMGGY9gl6ZW4We+i3aD9MAb/ODf0dJf2w1r8BQK+pZcso0JwV97mR0 HkQJVZ6/viKtQ5FA3hWJ17RzCCxtAXeTg5w/jQ6WkPk6RbC/dqFGLQTLtHMCi2ymK1kW pcVepKJoG6QgRUE7/iREByefWUHsnQs8C/1S/UO0DMaCB4Kik/J6DPkka7Jgz9ef/JUt MsHGdJ6bwiqVjYkFTdXNtg4YHFzPcmNjWFEVW2Mqo2zac2WWVahwyW36FLfx3Vc2aF2g TziA== X-Gm-Message-State: AC+VfDyjYHLNyvs2wH9wnYpf1o1Aw5Kdfy9EIoz65Cjaa2mWUdtcgET7 8Sp/FCCgtV4+y550dnrbLDNGtDUMYXs8Jrx0ccqLyQ== X-Google-Smtp-Source: ACHHUZ6Pb+RrF4G2y4aaH71FEJce5C+FydqiNFjzuifW7RzVOZQelbL54EJcfB0FumXcV0ePwos6NzUW4B8lb9ya5nU= X-Received: by 2002:a05:6808:220e:b0:39e:7c5a:1daa with SMTP id bd14-20020a056808220e00b0039e7c5a1daamr1355968oib.9.1686890462893; Thu, 15 Jun 2023 21:41:02 -0700 (PDT) MIME-Version: 1.0 References: <20230615034830.1361853-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: =?UTF-8?B?6LS65Lit5Z2k?= Date: Fri, 16 Jun 2023 12:40:51 +0800 Message-ID: Subject: Re: [External] Re: [RFC PATCH 1/3] zram: charge the compressed RAM to the page's memcgroup To: Yosry Ahmed Cc: Yu Zhao , minchan@kernel.org, senozhatsky@chromium.org, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrea Arcangeli , David Hildenbrand , Fabian Deutsch Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3DF1540004 X-Stat-Signature: ejufr36ahnare5qs959sarm3gyi4r6j6 X-HE-Tag: 1686890464-472601 X-HE-Meta: U2FsdGVkX18HW/vMzb8im+kiTgdIYTlNTxUnRSIVYaXpeVYGqMLzfChnDIfX6H+Sjy+SBitl+F5NmU0vLsdtp4pe/MHEuWc0E+xXF48XULoXmEkKDiFmpQq6lUZJnsv8k1vGrl55Mj8RXjy8+KhlrHlnz/YtkwGlanvRJM8mWtCEh7NgRyqU6gfNMs2cNL9VRNi7/xUN0PRa5poDmFssSMMsSNNPnn0hVUlhOQ77dpAGH5Z8POF1Iksgo/es7NkvR0VMkWYEDB1R3vy54NjxO+u90e2EP/GkeD8xkXZLHew8WtYtvfopd0aXTjeEy/rJ3HBvvgUhH2ofdTx2xZh32NOkK9ycsSJdt9bFpcUMufCL+hOw7nhge/Sa0F5LaEcw5J+1UiN0hoqUva959jHaJA67xKsMBxPYO1qFmOfCEJJev1G06KQ5NuP+oGynVdfCc95fGxnh6UqQNAlBLyl6sMV3jhN5+8BCVvbdTdMFmO1Qe23OxsSXctK4WKJxAGsKRA7Xm0XpnYs9EPkLOPFNeg1mq2OP55vInL5GIPYN4/a2BiIxI51tyqZz995v6k2vLUgFZKeJ2L5RGXvIimeeCmiKYBhd9KWa4ptg0Y0H1r5bNyQ9ptA35GkmkvDxCb2OTzdjUYKoJ++B1FVUpgzXIZ1qJzff+Y2oMwgDMrmEgtiQapmBImc93iS7vLBCWc/3peF172R1unQthcSlv9Yj9FRNh/Jc0Onyn0a00ST2of+yTMdumTO2hN/qifHb0Pow5oZNczvFo+GSpnVeDuEsBVlTqzu6nHrq+b0iBsoX9q0un4D+jxvvNq914oqK3wqoNfCL5opbr9ivqPGQfdgZ1k0nd0RXo6DgNdDWPfUth4cogqusQXmi92Em3LiJbF793R6y3stN7cuwWmncuHz7Vlaex8ZD17GxJEHSNoHZN55HSHL+f/Yjqh4r91utTwc84myWpbRhdONM4XVU7Od c25NFRf0 VJ/kvzYWzD/Q/tmsEV9ytyN0VlsRSmSIrEykmhXK/nkJ4NZwOTSbp/ETEKs52uPnsMADKfM2CKPwJV379X25UlpgJGkl2HAbZdRrT7rI/P3bEoczxhykpBKI23eCIDMux1ZdaDIOfxcXLw+WkaQ5gt/byT/dBaP4ExugXbXfltE891DNc6Y/pdZ6k7ycZwkZtiUnELBPmy2WUotwRLTfvBDpekwbk4HSWdDloDgzjx+EPQsge44/vAdGXkEYu2l3ru06eDpfVNn39CQU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > Thanks Fabian for tagging me. > > I am not familiar with #1, so I will speak to #2. Zhongkun, There are > a few parts that I do not understand -- hopefully you can help me out > here: > > (1) If I understand correctly in this patch we set the active memcg > trying to charge any pages allocated in a zspage to the current memcg, > yet that zspage will contain multiple compressed object slots, not > just the one used by this memcg. Aren't we overcharging the memcg? > Basically the first memcg that happens to allocate the zspage will pay > for all the objects in this zspage, even after it stops using the > zspage completely? It will not overcharge. As you said below, we are not using __GFP_ACCOUNT and charging the compressed slots to the memcgs. > > (2) Patch 3 seems to be charging the compressed slots to the memcgs, > yet this patch is trying to charge the entire zspage. Aren't we double > charging the zspage? I am guessing this isn't happening because (as > Michal pointed out) we are not using __GFP_ACCOUNT here anyway, so > this patch may be NOP, and the actual charging is coming from patch 3 > only. YES=EF=BC=8C the actual charging is coming from patch 3. This patch just delivers the BIO page's memcg to the current task which is not the consumer. > > (3) Zswap recently implemented per-memcg charging of compressed > objects in a much simpler way. If your main interest is #2 (which is > what I understand from the commit log), it seems like zswap might be > providing this already? Why can't you use zswap? Is it the fact that > zswap requires a backing swapfile? Thanks for your reply and review. Yes, the zswap requires a backing swapfile. The I/O path is very complex, sometimes it will throttle the whole system if some resources are short , so we hope to use zram. > > Thanks! >