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 A0892C3DA4A for ; Tue, 20 Aug 2024 21:13:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD0EA6B0082; Tue, 20 Aug 2024 17:13:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D7D3F6B0083; Tue, 20 Aug 2024 17:13:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C44C66B0085; Tue, 20 Aug 2024 17:13:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A7D596B0082 for ; Tue, 20 Aug 2024 17:13:53 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4C92F160599 for ; Tue, 20 Aug 2024 21:13:53 +0000 (UTC) X-FDA: 82473875946.25.FB48B24 Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) by imf18.hostedemail.com (Postfix) with ESMTP id 808D21C0012 for ; Tue, 20 Aug 2024 21:13:51 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=elwhjsSP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.44 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724188415; a=rsa-sha256; cv=none; b=OGNCghZnt68yzPP8YNsflBunX4kPsDI6rfONsbjAPt1SBwYen5j6U4ZKgCXvlavuNvLjWD YCFOYL0XlIZVOs6jQs6IWesqeRr/jH9mmwDMRghxDgCOPkJECF+9B8vlNON9512I5zA4MS BROFbeggfj1Y9xJ2WELt6b5yOqUGovk= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=elwhjsSP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.44 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724188415; 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=i4+1sMo/j3rHCjOJU20qLIIqTCnbIeNYA9x+rgF1IqI=; b=fBW0Jr0hyjm4ec/ZLtFa9FxSW0fm8Lwkf1/WAUsynghu3Nscbmyv5jEQpXOo1T7LQzTzZV cEkJaXaw1C9B4q9NwkugB6Td0DRRhyv5tsn5M4a3eUWQUpusrDyRtibzadkin52vtwn3en eXv2KwWp0QlDm2QMMFLyWzJmD9fJ14c= Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-6bf999ac52bso15498546d6.2 for ; Tue, 20 Aug 2024 14:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724188431; x=1724793231; darn=kvack.org; 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=i4+1sMo/j3rHCjOJU20qLIIqTCnbIeNYA9x+rgF1IqI=; b=elwhjsSPXgoj80FqnLGddN06QQwgc0k8zRhM1jkEHOsi3B6q7+Qpj1jpLb0tJg1Ptk 8AfrE1Ou9bMO5LA6yNObIWv570a6ujr9vJ7QlgMZ1R7WjHOF2d0hNZ6zUj6q0zpGz5Uj +jqSbr0S1BJUpJLUsVonPfoH1rQry8/tcpd8lvf73GyEbIi1Ep6ur1zqu6dlQOxwfcxU zd6JdPb9WkMl0HQpYS2X4l4tdB5ET/8C4wRFP2GhpH2fdNh+mKukUG2zOkUj+zDe1s+D v7mFSO0/CBY146KialdI+gNC8KulA07gpBIz21eTG3t49JaZVKf22TwWWs6iv7zLH71H Uz2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724188431; x=1724793231; 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=i4+1sMo/j3rHCjOJU20qLIIqTCnbIeNYA9x+rgF1IqI=; b=tAH9xYvc8qYVcKx+zxOQ45b0Y4i8PvNWwOIoycSRZHgT3iNWrC+8+gGblkdVu+FKtq t7npjCw0EZONZYcjGUuu6xtTU4r+6FUUmgO4pyhnAHnQ9kYPEzB2AcLMHiUH8PWsXrW5 dXHztJWUSslbRacr0Ws9KMvQ9gcFli4XH4lZ5c5/9IG2b6pMJhKMlEuHJYkuGtko0gtL bLJbEpOeJKx92j9qjXY4yUmcg2DZiPT6MuOX78MqQeEat/tiqFEtaTvJwOuOkGenJjyW gRu44hV4+p0/UaBRMkdEbvB4S+wBDVv6RdlNbJ67RDau4pB5iEO4CxRbHyqGIq8M1+L9 SIoQ== X-Forwarded-Encrypted: i=1; AJvYcCWmF4Dz5vXC4z3xCmjXlXDTqyFxEYardv5mxGxdQYiJEjws1MbRGzZiM2o9IcXVRHcyJR5S1hulUA==@kvack.org X-Gm-Message-State: AOJu0YypjxFZn1FZZK3spTPGeDGu+neRObRzcI18FMXA8E9selPxmC9D uzcvdCnhRBMLnAY5eH8XJhkYjDI3FoXWw3rH9LzS24L7PcksqjFyzyarW5n8bKdlk3dHqYSYTmU 4833QdCIuKrnAxhbS/cXRPUzdbrc= X-Google-Smtp-Source: AGHT+IH5LhCqlcHaogryi3OZO09ag2TddBUFxoqxmseS7pQXzwm+Jyi+88iMYqUV1l9R1Y2dgvvRWwpJkm+8mjWrLIE= X-Received: by 2002:a05:6214:4602:b0:6bf:6604:c867 with SMTP id 6a1803df08f44-6c155d77ad4mr7442546d6.28.1724188430547; Tue, 20 Aug 2024 14:13:50 -0700 (PDT) MIME-Version: 1.0 References: <20240819021621.29125-1-kanchana.p.sridhar@intel.com> <87msl9i4lw.fsf@yhuang6-desk2.ccr.corp.intel.com> <87ikvxhxfm.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: From: Nhat Pham Date: Tue, 20 Aug 2024 17:13:39 -0400 Message-ID: Subject: Re: [PATCH v4 0/4] mm: ZSWAP swap-out of mTHP folios To: "Sridhar, Kanchana P" Cc: "Huang, Ying" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "hannes@cmpxchg.org" , "yosryahmed@google.com" , "ryan.roberts@arm.com" , "21cnbao@gmail.com" <21cnbao@gmail.com>, "akpm@linux-foundation.org" , "Zou, Nanhai" , "Feghali, Wajdi K" , "Gopal, Vinodh" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 808D21C0012 X-Rspamd-Server: rspam01 X-Stat-Signature: fh9fojgnktdcx9gzm3obencyshpzdnii X-HE-Tag: 1724188431-699703 X-HE-Meta: U2FsdGVkX1/zdRryBPrFMnLXaYD5PAnHrq90ICignXm7Q0vntecjf3RWu32EuQzUhXrwcVCE0GLbNYHEbQX8jW5L7yGsK9BY70VBOANEC3JxVIr4aKz9PJ2qRMEV8k1DNEEwkqaDaTsoEXxfjgyS05e9tM0cXW9HPP3X6tF9J4nxUBCmteu59kUG1G7lDE9qXp408kDvXoHwP2bW2vPPptuTrGOLk5Wj8/6556FrWytw+spjyG+46kEUucHH6u3ifR4tpinTgpK7fQz0msMKHH8fdAtwCvMvw3KWntlc6zWDTWMLbccx9sDUT0LKTTssMyx0dOFUbij+jsERTlZDyCRFY2M0WUyLt3j4meyLcVKiaH6dDig/v0BcP1KXrJdEa61Oycx2KCyXt83xfCqX5tzEGl49G7k/TpMjrFySjKGFabH1qZQmaiOSc7vvgQGHfAGoDOAHviRoCJ283u1s3K2yvBirEfwCfza3LgPTgcm5h3ItKmkEfbix11waagqk6M4GUzYx25gPacX4GVAagNrzC3sRHQY+pxioYWPx+uv2QpAb9zTW+T5pQeRnRTI3wd3OjVMX9fPb4zVtA1lQ8d6etUDWEtUeyYrj98G+bbBZVNbKAPHhPGQzPQMrZhbwouaktnEjXkp/4PMfW7syugyr47NE7AVc3ouLtEIlf7Wq72S6EJT42QRISIAMg1SUgD03PFmCnDRTjUx2J/0mbWe4cdqs8Snoxisa1HtI7oTUItTCMXw1DEUZrPjotBKryU9JL9g7MleJFoK2ZXMTplorC44Wo+0yCAujs5Udtv+eTx+zUdtJZaZq6E7neq9LawxsS9zZgxSKFWebY5WOpRKkfNdJJj28mT4OeKpSn6sTJrcOBXzAqyJ8r7chq2glpIn14EnPQF0hul+c6HlHjbHs4SQK/EqBQgIf5sHR5ZWcINa5z9sHyb45rRiNqnV0UycqHqqFg+f/Vxndmsb 2of3S6SE J13uzNQjSy7iGd8aSa2TQiJVCs/w47+7LUQIPEMAtWeAemWHXWqW5DVnt1p8vmVSa1kaRfgI1Mkz+JzwuZkjaDEF/pYmcd7HTkxvPqZQhcAb4qiJHjqD46/DXV/VnCvcKpAtJshCMduQPZQHQhrwwOKezHzk47KNGy4ju9M2SS+MDYAp7E4t8/ozKfr+R1WhZZ4xGMc8e4ELKddTWJQq+RFoeT8q9A5Hgl5dowt6O+oGAUFPxUtcis2RyUaTt5MWvE1AW1NnccBJHuT87e5xDUB5gPQnA06794dVnUd8l1DKkha/2NjYhByIQZawAjBYK6+08mlIRU5dGOEKViOZeJDX2F4mh9KnS2RGdoWmp0H9p2NM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.079036, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Aug 19, 2024 at 11:01=E2=80=AFPM Sridhar, Kanchana P wrote: > > Hi Ying, > > I confirmed that in the case of usemem, all calls to [1] occur from the c= ode path in [3]. > However, my takeaway from this is that the more reclaim that results in z= swap_store(), > for e.g., from mTHP folios, there is higher likelihood of overage recorde= d per-process in > current->memcg_nr_pages_over_high, which could potentially be causing eac= h > process to reclaim memory, even if it is possible that the swapout from a= few of > the 70 processes could have brought the parent cgroup under the limit. Yeah IIUC, the memory increase from zswap store happens immediately/synchronously (swap_writepage() -> zswap_store() -> obj_cgroup_charge_zswap()), before the memory saving kicks in. This is a non-issue for swap - the memory saving doesn't happen right away, but it also doesn't increase memory usage (well, as you pointed out, obj_cgroup_charge_zswap() doesn't even happen). And yes, this is compounded a) if you're in a high concurrency regime, where all tasks in the same cgroup, under memory pressure, all go into reclaim. and b) for larger folios, where we compress multiple pages before the saving happens. I wonder how bad the effect is tho - could you quantify the reclamation amount that happens per zswap store somehow with tracing magic? Also, I wonder if there is a "charge delta" mechanism, where we directly uncharge by (page size - zswap object size), to avoid the temporary double charging... Sort of like what folio migration is doing now v.s what it used to do. Seems complicated - not even sure if it's possible TBH. > > Please do let me know if you have any other questions. Appreciate your fe= edback > and comments. > > Thanks, > Kanchana