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 1161CEB64D9 for ; Fri, 16 Jun 2023 01:40:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2DC236B0074; Thu, 15 Jun 2023 21:40:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 28BD86B0075; Thu, 15 Jun 2023 21:40:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 153ED8E0001; Thu, 15 Jun 2023 21:40:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0618A6B0074 for ; Thu, 15 Jun 2023 21:40:09 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CC3331C8DB3 for ; Fri, 16 Jun 2023 01:40:08 +0000 (UTC) X-FDA: 80906905296.06.E7EE1F2 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf26.hostedemail.com (Postfix) with ESMTP id 083D4140003 for ; Fri, 16 Jun 2023 01:40:06 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=Vxq9AlZS; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686879607; 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=rc1hgv0w9pIu6RN6uxj2ZcqEyGVaNMB+/vO2dnSoE2M=; b=lYhVbrePCc3YgI5Gy/Y1oE3ME5rv8xmNObPavu726I5YpwxI8EtT2JWzF83BW/Utzk0Ced lzJ8zsv0V2uplf1tMNJ79kOJ5rqX511d8UHKrwjHdJqtDh8UpiynD9YW3qX0yHHAGbnU5t A/Q3D8Ln5ijIyN94JdQaTsg2uVimhXs= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=Vxq9AlZS; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686879607; a=rsa-sha256; cv=none; b=aEqES3OMBX+TmV15NSVwkpGcE6pcP5gs88wJz1FNhj1mEcyMT0zmII/+vZl9g43Ner+0rL DT547s2vEpHRTMx4kePhzwh2V1sKqJRpekuK5iFRhz+mdptsDkovwn29NK6AnKXPJqxAto EhvaH4vpxSgfj0qPeap+sGVeoDbQVOI= Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-977cf86aae5so16441466b.0 for ; Thu, 15 Jun 2023 18:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686879605; x=1689471605; 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=rc1hgv0w9pIu6RN6uxj2ZcqEyGVaNMB+/vO2dnSoE2M=; b=Vxq9AlZSAbYtLe24k3NcJpfl8+3exe3cZ+meB1+4tVbP19Z7U82VSXHbfBSQXgv5vr syV5WqKnMtxCJP7q5G6sOXGjTNHlQaClT4F3Giy6YS7fTKN6KHeNibdGEjc79Un1TxbP ySnCOZEB2GG1yokV0FOdRsOAjzy+sv3/QRSZwPPpqjsw8xbgHodfLILs94b+Uv3KMcV4 wHIzyFiWQksAHIRx2hRZ/vqxEOQVlBsLbvPsvamsu6Q1er9/tYvm+vSBkDmVxUOJxE5v bsTcf3F0EThaxyYLQoPFhVQaxxNZAIrxizq1I0L17cCjyOojemz/oCCfy3HfXkzuDyhf ehQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686879605; x=1689471605; 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=rc1hgv0w9pIu6RN6uxj2ZcqEyGVaNMB+/vO2dnSoE2M=; b=MATfqivem3hWSahY5At9bEf/pEda3rOjGVVXC99WJNLAhzKypuWZmjtdOJb5Qria5k hdPDvTHuN4en7tLbzJ0x4UDSE/liLtDsEcH9UQsqmdlQ1Sf/OdQIFi2eD0rfaIPYi2Cr z7o3gXffu7aVRK34+RZ7td67Qcj04ZEUTtTAzmi4naD9DUw9njqyiBxn1YbpocnLIZI3 MY3UJGjSD0qXFSpjnZ8GsVsx4u983BjiYDNaiY2ym7iJvwydaQMr5x336WJ32zUWltVH bMYMGEvAlvRxdfnoffBFduXrqaLAd/vL9nVKqijp8MJC2/fOf7C5c5u5tsvBij70nDyw iYhQ== X-Gm-Message-State: AC+VfDwy1ddDMtqyBFlJhe+8O3zqxHJCUT59afH+KWnLTFjhErHEQ23D sY2UPe0+67YXvE7f3xbVtkXGlthlYTZ8W6fvQdhlTQ== X-Google-Smtp-Source: ACHHUZ779lZ17Te9wV+ANjzptQwTFMdsa51ddxV8vAA/0PdB5+k5vVmVegOJ1cM+FCvkgxDoSfrGfUYNi7LulQUTUdE= X-Received: by 2002:a17:907:8a04:b0:96f:bd84:b89c with SMTP id sc4-20020a1709078a0400b0096fbd84b89cmr492148ejc.70.1686879605208; Thu, 15 Jun 2023 18:40:05 -0700 (PDT) MIME-Version: 1.0 References: <20230615034830.1361853-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 15 Jun 2023 18:39:28 -0700 Message-ID: Subject: Re: [RFC PATCH 1/3] zram: charge the compressed RAM to the page's memcgroup To: Zhongkun He 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-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 083D4140003 X-Stat-Signature: m53xj57gdda3fjgfo9s685gu3srm16h7 X-Rspam-User: X-HE-Tag: 1686879606-249374 X-HE-Meta: U2FsdGVkX19o8vmk5NLMuPyADpYS/okhQZrjmICeF90Ik5c5NfBe260X05NhnSLFeSuJcH69QhkX+s+hp05pHUJZMByahz1QD3d6f4XZVbLCHCsciG/PKs1WgFBjsdyaeHoOfASYgLdZAaA7v8EnBAKPsH7jfE3n0skEX387ysEgGz4IYorgLOsW9x0DprEmx7KVh7CApB+N+2WKrUmNKbZ02K/8MSbEXvCgTa4BR94WivEX1mGwlN54VO5/MtHeZp5Ty9wnzxPDcKP9gZPWOvIQtfrSlU71Vh4XzfIEioxQu8p6L1ir7Cs9BrK6+J3/qHgPrudLs/OwHpeWccDoPCnCgV3jiYmYh/sm30uu4GwvKe3Y5m646ppPj+A7kFO7GpwzxrqWUN5pkDMJ8v5s1BUtNoErle5wzopMcgJLaKl/wGQwfuR8gAxZ/ns8nDdAh7ZD0aQerjL8u7kZC1XEo2bZup+oWzAmS2VcyZBfzQJoNLCakAISq3sCTFQX1sYhoGfIvEFGizSscixEzOGg/uDIfSeRLSG/2iX/e5kEz4NmSrW7cdhwd5YDk7/22aNlnYDaAoD1IoBOTQffAb9/50yh+fYO+AsT5EDo+/PUGUiZFjy3V0ZdapytNHxuM+m6ytUVKH8WqoLCGZVd1DOO52lW48GK9PeZiO8iicFT5uXbCHqgqirjwL/ZZkjQ1jToe5zXJUWReK4h7w/oBdCSAmLP52pRye7gv4uPVo6czu141yOcYIaV70yjrC8BQ4g27wWf5jMp9FN8mUMgCwnRRAqIglmgLoGHduaeCTdGzpq3J2/1vpM8M06bCVZu8d+ZtsISa1EIe47TtswDawzJ6+iEOiN4osnUkWs2LdyobN8jVSJiSRlGU6VDdm2YVqbNvXkJ+N4xidQFW0wI3SXmb8OQN0FNLtkJEvWUSEPia7bO9/gRTLSG5mQ69GtlGG41sPCyKqh9uec/BG3drrQ 4Rk5zMic 3KOHVljiaTNxhhhfW7AxOJZcUZ9hcT2BRW7yC7ISplOAL89KjuoP3gMV3A0w+vzd8PUJaTY9fyJiAohlr/cWCD83aWU8kb9Nzx9tFYuY4VaVqpomtgtlxiiO3D18Jw91+qAsN9IhVEJHa8dUhXkZ0hImy6wNDQpZDWOyFMCyX0fq5P/aXv4Zk/b2imzz891IbMlzWwUBSgt1udopVch1DoNRcCUzuFHRzu8CWzPOte3UOWUQ4xc6/PGeZUxx9OL4+HIAQ91nbS8c2mvLKy/ZvBVqzUPe051404EBXigF0QFLNMrs8Ml3j9tT85II95QuRgQK05pfCQRiHQ9FegUgjcyXTfLmhh9ijrYpOZdWPmp8F0XdkIS0CEFvniQWGUAtlimMPtwqp6dZN0SE= 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 Thu, Jun 15, 2023 at 1:57=E2=80=AFAM Fabian Deutsch wrote: > > > On Thu, Jun 15, 2023 at 6:59=E2=80=AFAM Yu Zhao wrote= : >> >> On Wed, Jun 14, 2023 at 9:48=E2=80=AFPM Zhongkun He >> wrote: >> > >> > The compressed RAM is currently charged to kernel, not to >> > any memory cgroup, which is not satisfy our usage scenario. >> > if the memory of a task is limited by memcgroup, it will >> > swap out the memory to zram swap device when the memory >> > is insufficient. In that case, the memory limit will have >> > no effect. >> > >> > So, it should makes sense to charge the compressed RAM to >> > the page's memory cgroup. > > > While looking at this in the past weeks, I believe that there are two dis= tinct problems: > 1. Direct zram usage by process within a cg ie. a process writing to a zr= am device > 2. Indirect zram usage by a process within a cg via swap (described above= ) > > Both of them probably require different solutions. > In order to fix #1, accounting a zram device should be accounted towards = a cgroup. IMHO this is something that should be fixed. > > Yu Zhao and Yosry are probably much more familiar with the solution to #2= . > WRT per-cgrou-swapfile, to me this is addressing #2, but I agree with Yu = Zhao, that there are probably better solutions to this. 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? (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. (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! > > Lastly, this patchset, while it will possibly not address the swap issue = (#2) completely, is it satisfying the needs of #1? > > - fabian > >> >> We used to do this a long time ago, but we had per-memcg swapfiles [1[ >> to prevent compressed pages from different memcgs from sharing the >> same zspage. >> >> Does this patchset alone suffer from the same problem, i.e., memcgs >> sharing zspages? >> >> [1] https://lwn.net/Articles/592923/ >>