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 C0175C54E58 for ; Thu, 21 Mar 2024 18:44:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3AD5B6B008A; Thu, 21 Mar 2024 14:44:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 35DB26B008C; Thu, 21 Mar 2024 14:44:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 24CEC6B0093; Thu, 21 Mar 2024 14:44:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 164E96B008A for ; Thu, 21 Mar 2024 14:44:59 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DBFC41216DF for ; Thu, 21 Mar 2024 18:44:58 +0000 (UTC) X-FDA: 81921923076.07.386F130 Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.201]) by imf06.hostedemail.com (Postfix) with ESMTP id 1002218001E for ; Thu, 21 Mar 2024 18:44:56 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=jbdFomG2; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of 3KID8ZQoKCFEH7BAHt05xwz77z4x.v75416DG-553Etv3.7Az@flex--yosryahmed.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=3KID8ZQoKCFEH7BAHt05xwz77z4x.v75416DG-553Etv3.7Az@flex--yosryahmed.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711046697; 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=SCfRwWBm0rP8eYIoIIToNVzQquXUQ0KORkBg9UBOdAU=; b=ZFOqeWqJe+8NtdCbomvAZanWPS+aZ7Ap8q9ZxK3mliPyu9pnG2kHnReADaeNGJVYQnCTea 9clrO2EHo/4uqUOTvUsCUQUFbdsA6zPB2IY64DuG6rfOPJePxIh9QHQYU3M4iHsDG8Vdvl kkl7iD74Kf0/PNjQdBro3K8zP7YS1H4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=jbdFomG2; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of 3KID8ZQoKCFEH7BAHt05xwz77z4x.v75416DG-553Etv3.7Az@flex--yosryahmed.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=3KID8ZQoKCFEH7BAHt05xwz77z4x.v75416DG-553Etv3.7Az@flex--yosryahmed.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711046697; a=rsa-sha256; cv=none; b=zPV78tpivLhso6hnmpNmJyh2jSFXrKcvFQvVtQiSx6CYJBd2wdDVZs/pyGb/ZKmuEAQoHv HpuY2pRgcimKGyX6v+7x4kpq+iYvxZzAIt2OaK1fjDxD/NlDdUALTEjPzerA/qnko/eM8c UbNfXTRzR+fDqfWlavuhz0PcVZMEaNk= Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-60a2b82039bso19175297b3.1 for ; Thu, 21 Mar 2024 11:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1711046696; x=1711651496; darn=kvack.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=SCfRwWBm0rP8eYIoIIToNVzQquXUQ0KORkBg9UBOdAU=; b=jbdFomG2UJrM2kPGwC3MfOQD1xCMpRneAAsC899ts49he7H9Sx7ckcBGU/YrOs+WGm ZWD9amdTA/6x6FzsYTGonpxbre4WoixxQZgMhubf8t6c73bze7DeoPpJaEB7dfOqUHUU HtrEdv9oxNaLH1J17fpsSILZ952mP1UPX2k3RjRKCn9/TW7EkLA5ADwezTXFFAZRGq8a AbEHUUaUHlz80/LnmbeeKLvP6Ffk2SssjkJEvQ+F4A073V9cdiU959jBP2L4jsZZcCm+ +fz5BhXM74xkFLbTPeu4vIyVD3wzZDx4AerITPbqEa1vJFdaoOuk2ptCxlFqvtBtuTkt lMWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711046696; x=1711651496; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=SCfRwWBm0rP8eYIoIIToNVzQquXUQ0KORkBg9UBOdAU=; b=pM36Y/CkzLmYU3fP1PjFZJzXZqsU9TPui1Vcwd62s0qt+ZfO7cRpuCt5ceGtQ9RYVc pesxxUc7PIwOB8qZUgTkJFRDSd+3wZvTURv5HrF59LRwLN5JWGQ73/c7Co60EihXsycA Sp3tOtFov6Mvb6tK8gFP9NkAsYRtMN22d+GiIc/zpgCfeaGAJpEHlZtHNnGGebiNRZ9K 8Za5kesVwQzLaG3/hqeXX2FkjKyJ1P0WgEtggl6HYVqC3bfDdDV4RZ4iGItkEf21PVaK LGjFf85QOv4M3cH233BO9r5/KxKeM4Novam7/Kh9ghOkTSm7cZtUadhvCP78hABGzXUe ZXeg== X-Forwarded-Encrypted: i=1; AJvYcCWznWOI+ljGIve/IetR74ou9xU4ARMkoZitZIdkMZMZ0hCk7QAd8NsGYovqsmcSbzVElfP+8EbxDGML+89quIamTNk= X-Gm-Message-State: AOJu0YwSNNBdgOZ5nNbm7YRXh2kVXQiCk4a2jROmuc6KrY2+5Oo1HWaz jInizcFIUOCMM3H7JAPVbJh2nT21yDgzHwZJeznhUIVfdVHYX28UGhncJOcWfWRyVT2+lIayY+o Zh0u80f0TQcRm4RNTYw== X-Google-Smtp-Source: AGHT+IHYf5py9baqTWmzMpHhdWABpOXfmr6B75MTZRbUAre42dQs27D6CCIknQhSDdt2cxxJjIGl7tgLBbQ0Jnku X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:29b4]) (user=yosryahmed job=sendgmr) by 2002:a0d:cc54:0:b0:608:d499:3439 with SMTP id o81-20020a0dcc54000000b00608d4993439mr12422ywd.7.1711046696165; Thu, 21 Mar 2024 11:44:56 -0700 (PDT) Date: Thu, 21 Mar 2024 18:44:54 +0000 In-Reply-To: <7d7b755a-e13e-4267-b1b5-a4e2ff33d6e0@linux.dev> Mime-Version: 1.0 References: <20240320210716.GH294822@cmpxchg.org> <20240320211945.GI294822@cmpxchg.org> <7d7b755a-e13e-4267-b1b5-a4e2ff33d6e0@linux.dev> Message-ID: Subject: Re: [RFC] Storing same-filled pages without a zswap_entry From: Yosry Ahmed To: Chengming Zhou Cc: Johannes Weiner , Nhat Pham , Chris Li , Linux-MM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 1002218001E X-Stat-Signature: sxnnqag35nkg3ywuc6cdycdzk4ftc175 X-Rspam-User: X-HE-Tag: 1711046696-348113 X-HE-Meta: U2FsdGVkX1+xIqj2bJQ5NLgi8Yb0KkOoVJJKPQEofuFe87MkqKC+wDHUxajtS5/djt1KDEaccbXthGNeud4VXcqYhu4PAVM7B0NfxkOIAndaDi9S7qwfb43DiMplpusaPC4Zy7ZPaPklEsTXqf5fam9szN+SGgQMLwDO1jd/p6BJIyVNxvpW44jaPNQENdnEW2/26/qj3mCaxrT3cTi1tqrPdeL6vjhMtN0WrPwq4MgduCyiR5zciJMAB/sIqg1gb4rdqcc72mr+WpXpunqS+hhXMu31otXWGpeDKLOk1XvqbwJICte2Yh3Nbf2VZsMjhSY6mEVKyXeE/ZQeBcT+Jiwp11mNMehw4XV7mqB0/v2YTqpJp+9Rcv4FtuxvAGvy1oQUfBs7jxMQtHq582m3Agfyh6JtvhgXfURP30urW9CQWbWFeXkSl3ZLZ8DgfgpXq2Iaxm7GyDz6DVOG5CdX0M73xku5Vosf+jauXEGYCtTPycDQ1qg3+yCQRD35U/2dbRYk+6n+zgHHNo2aYABL1O1LD5LhcvOo68g7Sj6kZPkzrxe1bgEAc7oeRVzeRNnZWwAcfpeqeyK3EusoJthFu24fv71Wp/bMgq2wraARnvetul3EgTJDda9n8UQ3tSjH8lNrQjJ+nI4jBZ+Pkp9n4ld6bjWbZyN7cwx/+d7NIyOechCcasIqf3JfcOjNgwsGjXDMaj/GpByDjqFOVP8baD8+0hs2Uv7cKlzsKk1twqZeFUG1FZIC09PndSw1d1HcxXNTIbtrx8crEiEteI691na6ExkjdSjtkwbQ7tyeoqIedz2Un7fjmmdMpiGSWDfHMz/RNbvFPqEqYf7o83bTUVqeBwugyM7bv4WLkxyUHTRotEmv0AOcgwwN2srHhLF2Mmp5PfOwoN1e7/ZLqc6DbmCcpW6lUb81BcuUTZOTLdxDXS33BMl+kP1I5csyRtTYf7zevBC7pxBbBP8kAMJ OUSsBdR3 mCdixFtEUAfp9ikxZ4pUbqytvehiuxvL0vNsmHF36as8C8woopi+v8s65XqAs7HUHvZk33qnZezvD5c8cEX+fBJBgyTLU20y/wHPH6FLGrIFz8+ZfBlvyV7d7q+7khGiGihly004P0kkMObkNjt5XJmXvj+kl4Rn28nY1/Kv4tL4tv4DkPCgaYcQGl7TuV4Rvsu29S67fucQqKulSQymQ/WDt5DUZ5Xr45FuN3HMEH4f3Yglpzn1I4A6xJwsHweJoFd9jSIMRD2ttWPzs87Sy4H4poDVW96tfIaAkm6ejX42S1fyPYHLhTzoNjq+cOEUoWYnxgMNYOoz2+pRaMb2obCOjFuup5SOry2CFI4ejhZDEdTPBiDBH+5VsPZhCSfzh+DhS5AGAuRJEQtd8keaUle/eXEZc/A1JqedcEzr8cWbMOrK5Jpm43P79GWJBYmzDWJpv1dNGe/DhrPhl/RsVAjBdRGsS99I4y8LSSSjukMWWmiQf+v028h3rsgD+v5spilIj2OQ4DXgfP1FFAIiEmRAPGMvNX1fUXLv08q988Id4Igdflak+waFkr+y1I7XCHf3xLbjXg8RQhN4alQFAbh0bwww+Dsy29OtGuajnLCMMjNAH9WgRr1sDpEHwwhDEXz0LR/xVwkHp65+l2EvKF+dJp85a+hUoeNSrJVvILD6yM9yJbzJuQgxo44NthHbcG34l9EQiw1gWO5zvxEkrg9wupDpPY+hHLWNV+U6vefWbdBDEmTN11xZQkfgl29jjfJC7 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000483, 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 Thu, Mar 21, 2024 at 11:40:32AM +0800, Chengming Zhou wrote: > On 2024/3/21 05:31, Yosry Ahmed wrote: > > On Wed, Mar 20, 2024 at 2:19=E2=80=AFPM Johannes Weiner wrote: > >> > >> On Wed, Mar 20, 2024 at 05:07:21PM -0400, Johannes Weiner wrote: > >>> On Wed, Mar 20, 2024 at 01:49:17PM -0700, Yosry Ahmed wrote: > >>>> Hey folks, > >>>> > >>>> I was looking at cleaning up the same-filled handling code in zswap, > >>>> when it hit me that after the xarray conversion, the only member of > >>>> struct zwap_entry that is relevant to same-filled pages is now the > >>>> objcg pointer. > >>>> > >>>> The xarray allows a pointer to be tagged by up to two tags (1 and 3)= , > >>>> so we can completely avoid allocating a zswap_entry for same-filled > >>>> pages by storing a tagged objcg pointer directly in the xarray > >>>> instead. > >>>> > >>>> Basically the xarray would then either have a pointer to struct > >>>> zswap_entry or struct obj_cgroup, where the latter is tagged as > >>>> SAME_FILLED_ONE or SAME_FILLED_ZERO. > >>>> > >>>> There are two benefits of this: > >>>> - Saving some memory (precisely 64 bytes per same-filled entry). > >>>> - Further separating handling of same-filled pages from compressed > >>>> pages, which results in some nice cleanups (especially in > >>>> zswap_store()). It also makes further improvements easier (e.g. > >>>> skipping limit checking for same-filled entries). >=20 > I also think this is a good idea. :) Which could simplify the code too. >=20 > >>> > >>> This sounds interesting. > >>> > >>> Where would you store the byte value it's filled with? Or would you > >>> limit it to zero-filled only? > >> > >> The dumb thing about objcg is that for same-filled entries we really > >> only need it for bumping ZSWPIN. Nothing else. entry->length is 0 for > >> them, so even though we call the charge function, it doesn't actually > >> do anything. > >> > >> Loading them is cheap and doesn't involve decompression. An argument > >> could be made to exclude them from ZSWPOUT and ZSWPIN entirely. > >> > >> Or cheat a little and bump ZSWPIN for current->objcg instead - > >> probably good enough to make excessive thrashing discoverable by the > >> workload that's directly affected. > >> > >> Then you could get rid of the objcg pointer and use the xarray slot > >> for whatever else you'd want. > >=20 > > Yeah it's only useful for the stats. Using current->objcg would work, > > and should be ultimately pointing to the same memcg in *most* cases, I >=20 > In some cases where the current objcg is not "correct", the testcases in > test_zswap.c may break? Maybe we can use swap_cgroup info to charge the > stats to the correct memcg? Not sure if this is feasible. For cgroup v1, swap_cgroup will be cleared from mem_cgroup_swapin_uncharge_swap() before the zswap load. I think the current objcg will remain correct as long as swapin happens from the same memcg as swapout (or if swapin happens from the parent memcg and the swapout memcg was offlined).