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 DDFECEB64D9 for ; Thu, 15 Jun 2023 09:33:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 534C38E0001; Thu, 15 Jun 2023 05:33:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E4BF6B0074; Thu, 15 Jun 2023 05:33:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3853F8E0001; Thu, 15 Jun 2023 05:33:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 266C76B0072 for ; Thu, 15 Jun 2023 05:33:13 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E0C951A0B81 for ; Thu, 15 Jun 2023 09:33:12 +0000 (UTC) X-FDA: 80904468624.03.F53127A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf30.hostedemail.com (Postfix) with ESMTP id D31B580017 for ; Thu, 15 Jun 2023 09:33:10 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=hByuYn2j; spf=pass (imf30.hostedemail.com: domain of fdeutsch@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=fdeutsch@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686821590; a=rsa-sha256; cv=none; b=YqofkNi4xN76GwrKViP1DK1tiTYWu2ZFgRZ3I2w08/mbVcQ0XN2pqdr+0GQULkZwAHqoTN tS8JljV97KlVdkhyoqdaAv0tfxqXpIxQg0pVly6y0yJg9XZTv0TNQ9yNrwCIblsCdfw5/2 iIHB7YOEoL/TAHtdkwXaoox7OLr/nCs= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=hByuYn2j; spf=pass (imf30.hostedemail.com: domain of fdeutsch@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=fdeutsch@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686821590; 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=By+qTcV00Wxy2aMxnryfOK5l7c3RlTf1drDswP2UWb8=; b=Y3Ferhkk5bo3bYrN8/tj4oSoDSwSLuU1jBCUf/wmqGxmE8QBGldTnjhVkJN7Ldv41uG0Ou to1D7yIdjfRRjbBheqTJ2JRao5x/XJuqeb5/Lgy1HzFEKsIP211Rm+7UmgDmkw7P+Bi2ph cqqkqn7nUDIMPescfacwuMs58NC2s+c= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1686821590; h=from:from: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; bh=By+qTcV00Wxy2aMxnryfOK5l7c3RlTf1drDswP2UWb8=; b=hByuYn2j1Yo7fIKVAav8sR4AvuvFJ1yF/azt7oW8mJoyaVBzbbqjziKeO+cO6XAOfZWlH4 lkGkAIW3be51Frfg1BXwTyUSzUWABO5Tbwl2F0Gl40KBcKvIHJ9WZHEqpiu/MevTGYLZ1f BlCmIsm7VBPawCF5xBmkUKOEC3UG11E= Received: from mail-yb1-f200.google.com (mail-yb1-f200.google.com [209.85.219.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-335-mnPcctScOgugW_zDoAXbsA-1; Thu, 15 Jun 2023 05:33:08 -0400 X-MC-Unique: mnPcctScOgugW_zDoAXbsA-1 Received: by mail-yb1-f200.google.com with SMTP id 3f1490d57ef6-bb2202e0108so1717256276.1 for ; Thu, 15 Jun 2023 02:33:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686821587; x=1689413587; 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=By+qTcV00Wxy2aMxnryfOK5l7c3RlTf1drDswP2UWb8=; b=hMhLmhKVbwmtLzM0ogVhOJONq87HDFYPzTkmHF8TQ0+vQ8Puea6+ewFYx6izqGlsbd choVA7G0Go/fU4N8IRS9asrrBpB+CWHb9fFuY9fL8IOFcqSLFB+eLeDRalGYwgipAy+3 o5Y3895CYaE8KY3bnscltxLDWxzfBdosxBiITUjSBnwDVI8ywFDNK2I9BGQ8m6ndgIaW l8XN104dKxAMWzio35ofYhKHJA3Y4B/scHK8ZYHMHAmQ9P2GH1CbGgRJNNJD8D5poik9 L8dutOt7G1Hui6BLtZsIa3Z+hzIyHhLbsoLYLyEScSgBkldc2jk8CO+p3B0ab/59Ca/v df0A== X-Gm-Message-State: AC+VfDwcw8Gx5Bhe9iVPRP3DxsrwZxQcvgn31P7T2A/YiLpRkZAWkJ9M 01ERQv8yrW58AN5Dl6+Dm7PlSEiQcWHEy9XgTn1AWg4e88F2O7y4CR1KF1Nv60ESxZb5eSPEQ2M bssY67Iv8GP8soze8FwuLu4VRoLIdf388JOgcTA== X-Received: by 2002:a25:c5d3:0:b0:bc9:1019:541 with SMTP id v202-20020a25c5d3000000b00bc910190541mr4511770ybe.8.1686821587596; Thu, 15 Jun 2023 02:33:07 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4wzABWOyoHZ4UD8kzzizr6eF73JPT8TMumNPs00qj7Wnb72JdlpUql0ilmvKC4QWb9uUl3XgGitZNA39kA0zU= X-Received: by 2002:a25:c5d3:0:b0:bc9:1019:541 with SMTP id v202-20020a25c5d3000000b00bc910190541mr4511761ybe.8.1686821587344; Thu, 15 Jun 2023 02:33:07 -0700 (PDT) MIME-Version: 1.0 References: <20230615034830.1361853-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Fabian Deutsch Date: Thu, 15 Jun 2023 11:32:50 +0200 Message-ID: Subject: Re: [RFC PATCH 1/3] zram: charge the compressed RAM to the page's memcgroup To: Yu Zhao Cc: Zhongkun He , minchan@kernel.org, senozhatsky@chromium.org, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrea Arcangeli , David Hildenbrand , Yosry Ahmed X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: D31B580017 X-Stat-Signature: 6mi976n3u9swsjzrj9z9n8yhspc9xy11 X-Rspam-User: X-HE-Tag: 1686821590-97734 X-HE-Meta: U2FsdGVkX18VXeU4tb746EroPivElV+CdahvvtVdcEMINemXlraffpacijottVQOjYOzE6GzoJcCUsqQk/BjdDKJlNtOMRomnegRI1A5Q6Y3ZQVzOzZzD9PFcbeWg37sP9L96OcypYp3/YzmLShGPdZkPoMUHSHMmrQ7SRzokFetw7gzcf11Ymfl01wXwo3Hdne8GCXqfhAQhEPkSc1Vwr3FPUoGPjlfmPFBbcO0EzBLtSR79g1t1i02DXsojcqMaQTYkvyD92hqVouDIjipCJN7H9UahTbyYFhxDRco59bkH5FVX/KCBJXaQvvtM2ZqtMLVh6kpif1sgGBtZvVwgBLcQLMKfMxx7EGtohpLDgplfelrWTL57um7EU70OF9n14NGN+kwrohB5ILYVk3L3stgSHaMHr/SW4mNtFRLRUlGlDGJM/yRPOzU83b+TOpq7mubHeYnxTLUA5rnpVqUqTzPAdKqxQyEwbpNtNBQWR8B7VdLCjOZ2ls76VVa2qjho/fnzU9qJ6QULo8oI2MUYAiGm650SZ7AF4QRadd0UPmh9Dgh7EAzZNnnvH/TPij22SE9s6Bt0FDUZmhjzC2/yegIZR4w4smUnffNrdm2efurgrTStaNjQUGkmwRTKhQH+mTibSnuREn55Ph8mn81e/1eOB7Yojt41UUYEuwpU8q29Fb/x9F6vOX7VFiLAq7Za8DwZvWy1WYdjGW3LGC1D9bYWNRuR0ZCZNl8l7goQ+bvlCiKGNM23IIpTiks9UuAonRQUTRAILuJcMvneaPbL10AijpORIPBwgsAkKsnpqX1AC3ap62Vd53V+sycqsByJfXgpkqFMw4JdaJyq1yrI6FFG6DZgb6nUUmrVZH/oyIuTuEYcK01HWeqpt9UnaNArwG5rSByteUsPhJ4/Dz6Yr9tFOgADpOmdg5qol6wUM1jNc2r9Wahf/kol6KKY5x4AUNj97iL6G/PCZy1RWw Vk/ki8ge euLOUCFcklTKXaBSdx/aMaftmUZ4nZZRXkz0ExxMmbrlWH0P+xhY5zSknmPleO/LSekIHThQ8tNZmAFIoSANv5mNpnYlKp8gV2FTjRB6iPw4S+S1orD7NL1qAUh5XXDBqlGkJkyALfnu59j0AN/ir4o704lapkHuip8pKe2s6Bhh+jkoUHQpFZ9dJwZHGQTvbukgsixWR1j6VchPxokw7j7JY/8eODNhC3acOyyigbPjEeF7dBV9JI+PjPDvUNlNZJsfWuSDz4KzPwTM1kcA7SBgcw4M32JAICCAkoP/jp9dofdwZSO9NRM2HG9CU6wZaaa1VCoEWpMIFJi1MUzHLvgSWwA== 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 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 distinct problems: 1. Direct zram usage by process within a cg ie. a process writing to a zram 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. 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/ >