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 F01ABC197A0 for ; Thu, 16 Nov 2023 20:19:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82AB16B049B; Thu, 16 Nov 2023 15:19:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DA286B049D; Thu, 16 Nov 2023 15:19:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A1B56B049E; Thu, 16 Nov 2023 15:19:21 -0500 (EST) 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 59EC86B049B for ; Thu, 16 Nov 2023 15:19:21 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1D4CD12070D for ; Thu, 16 Nov 2023 20:19:21 +0000 (UTC) X-FDA: 81464932122.28.25E6588 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf02.hostedemail.com (Postfix) with ESMTP id 4391B8001D for ; Thu, 16 Nov 2023 20:19:19 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=CuHNSUTL; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.49 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=1700165959; 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=1OgdBdxfhNkPsuCj3CVQO+gy86aXcSm+tfVyfjz90gM=; b=53LZbqMWJ3nCzC8CCAWvqV1VtKtqRo4sA4b5uOvxfJerWiAsFPj+SAwmIafwrR3Oif/nWG 9rrQb4DWbs5AsOfc5XcFp3fAYwE1B//qWzAlmsA+0wC2JsocooO2qsfV2MUGe9mKIyoUXe PJ4SwPCmsV7Snod0Y8RAexNWxyAthj4= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=CuHNSUTL; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700165959; a=rsa-sha256; cv=none; b=zkVdShvsL56Vx/GqTGViy2cgJR+BOaAhxeN4yEnjSo2Fwxy48HYosxu/Od0aWmDWDS5TmL Z1RUBxYinMOd6vAa9c7jgaDoY1NVYA6Aa1flYOcQ9cqnaiZBVe+brOhfCGbiyTFLx8/nQG fw0kdrCpffxZOz5ZGsUbwwQpRJdSnG8= Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-9e1021dbd28so177108766b.3 for ; Thu, 16 Nov 2023 12:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1700165958; x=1700770758; 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=1OgdBdxfhNkPsuCj3CVQO+gy86aXcSm+tfVyfjz90gM=; b=CuHNSUTLeYPBza/2IpcrtvOAm5qAuVQLJo+ikmptL28DZupS7KRLXC2s6jE/hZSaVE V61f0g+v9MC13IdmOpUm4Wp8B2xuJar7RmF/4w1PX/3HBPvReBWo26G1m5nCct0RWqv/ yQi6q2dEkcupZI78yy9kIfeqFWxjxrKCfBZks+WcW2bMmWnvDuQzynoYWm4YCX92wGzL kreuTNrzFtR0od8aEkfJC9FKb6VFfq5e2JnXbE9JLUDak4upQbl8pKL6xiMdkoJu7moX I+VGPlalhuHu7dOn5fP4z1B3Q6y/dUFKab4KmyTvIX5uLQECPFekaK6BB2zab5Mz18BA OwgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700165958; x=1700770758; 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=1OgdBdxfhNkPsuCj3CVQO+gy86aXcSm+tfVyfjz90gM=; b=Od1BK8FEArBBU4yOX2FVps2JUr9eESoybWOSiIGAw5/4ILF0wkW6QEBhgMRn6KpNwU EIgVs5KUI/Y6TBpQrh9dvW61XDuQNr10+sPeEBfzpLshxC3xQbtbmY1WdB+4Dm12h4AT uz+5UWft8+m9fgLqQ4PSFXdP7pmrK8J/RWKsjf5KTQbGmqVboIEqnsxJkO6En8bSjwfm bSgD6wzo6VGYo7PUOYldbvFXD4kyn7CUR1CDuw0Y3na7We2S+7k1Tf+9JtQiZPRygc5D AjK63z6Hf8prriB7XUebOPJjFVeeYpAq6MgR/WPHpBiOK6RAEEip9E4cliLWH2cBUV39 N3/A== X-Gm-Message-State: AOJu0Yxg0KkwamsoTcML4t/8sE+AHna0IpIvFRdI5z6Roj7qjuqzKPC6 veKU8EKQnfTuBCvl5U4eIDnIk8HEhh4vpWdCB8Lt8w== X-Google-Smtp-Source: AGHT+IHg3EGd0I62ta7o+TPCWWwtNPcxX75RJDJGXptVhnsHRxShshMV7iQIK1LHDeOA/VBB9f3MP/0YjZjxs13sMoY= X-Received: by 2002:a17:906:404:b0:9e6:4156:af4f with SMTP id d4-20020a170906040400b009e64156af4fmr13053218eja.55.1700165957515; Thu, 16 Nov 2023 12:19:17 -0800 (PST) MIME-Version: 1.0 References: <20231113130601.3350915-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 16 Nov 2023 12:18:38 -0800 Message-ID: Subject: Re: [PATCH] mm:zswap: fix zswap entry reclamation failure in two scenarios To: Chris Li Cc: Zhongkun He , Andrew Morton , Johannes Weiner , Nhat Pham , Seth Jennings , Dan Streetman , Vitaly Wool , linux-mm , LKML , Ying Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 4391B8001D X-Stat-Signature: 66jggy6cf4j8afgo3d3gxh5u6x5ih5je X-Rspam-User: X-HE-Tag: 1700165959-217888 X-HE-Meta: U2FsdGVkX1+RRAScYzehLtwBA1at+iNk34v8mYO/k3cmYmcNxInFRCqfNHWwfv17OQcCMURq9a5vBVukyaeRPC1pn/2vPsNDcOsZeFevbITvbFVxYr2IZO1KeVTdN7ZZCtaGMRPKepIowgTJNoD0PddPIOGGflz+UVAC3KIR5343qxQAnQbiEWmttQILYl9gmR7YsFZ244cCbEvm9Vs+aGdgoKpLIbbJYWh+Hu4+sNKHFjZLwhZmWZ699waKruPNL8aLFzZPfcJ4VdRQKEzn3bQL9K4MEX6nuE8HGgld900y/fxKlOjscBbfdYW9vG2OOK5JVm/X7eA36abOQPVd25MGGlHLYhybfSq+rsA5eBTgid2hv037/s4epaVo2UzbrMp6KTEggHfCz5Gn1MO0EAZ60oqHSoNTMt4oJYB+E4lhiJXRG/VNlG9BeAYZYsrZ3HOYM4GfKh5K9GEKYO3+cDyCvjzf/nUaBDKDgw4keWan3pySszllDBZpQMqglfA+xDhjcGg2j+HVEWsQw1ewr5iBSpRgF1/C+KRgwTeyyHC6uaNy4hZpwP22pjYL/E7GU9tyYXG1FrpiCurU25FChjtQPscydjlrAxUNANr8j6+SdHCDUBFQyjHVirVCXjz/8i2xv0hmVyGR1GQyYmg1zk7NCcbUun+B+mSDjTmv/Gv99Z9mKRmaRbTHVJNIrt7UhG2Lb46V/DJmHfIMuoZ8WFHciAzOeJh9ml+EbQTFtArRQpXLosy2o4lmSWlGbuubL0+y5Mvw09MvkPhy3j2Wy3PLlX5Y5c9wT6wTLdtDziD/10aCecJQHFXARUCQZj92xioMdrlPHpYhTBeHVUpgmtoQUAY7CSXeuWRezlli4ye1uHl6Huf+8Cp9KX7verjsJr88ov1xdf6Jm9SHdDOZXdh9pnLXvmtCEeE4WqpNvf5qnvQl0SkkOD2wwOfrfV6fugEbQ1y8uIUNlbtDZ8E lmC2RJBs fhRej4Pf3xE+SWBwv4kwao1ZiFl61FzJxqREehuIp74RGvO2Hz+iXHExHjV5gAnmV53qIKxDnI4XfDAixCPkQKiT/5nRDSmS/CnS3YDhaarxxcQduzyFNu+XbgxgkvDMWKAZTRF+AO10CB9xatzini1Dl8ElwUpWq7VAgjFZJG+mzh4cAYRasPvePrYsd9ksdA8M1+ndsS9lMmntlYMFicxg2yt6oQCN+PyyWLyNLMr+i8VR7Rgclvrt1Fv/gCih9CjkH5W61pmvYC/cV1qkE8Nj8Ef4nVp7IsAASByQCYIbp4xMNnTz5RTrVRw== 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: List-Subscribe: List-Unsubscribe: On Thu, Nov 16, 2023 at 12:12=E2=80=AFPM Chris Li wrote= : > > Hi Yosry, > > On Tue, Nov 14, 2023 at 9:16=E2=80=AFAM Yosry Ahmed wrote: > > > 1)The swap entry has been freed, but cached in swap_slots_cache, > > > no swap cache and swapcount=3D0. > > > 2)When the option zswap_exclusive_loads_enabled disabled and > > > zswap_load completed(page in swap_cache and swapcount =3D 0). > > > > For case (1), I think a cleaner solution would be to move the > > zswap_invalidate() call from swap_range_free() (which is called after > > the cached slots are freed) to __swap_entry_free_locked() if the usage > > goes to 0. I actually think conceptually this makes not just for > > zswap_invalidate(), but also for the arch call, memcg uncharging, etc. > > Slots caching is a swapfile optimization that should be internal to > > swapfile code. Once a swap entry is freed (i.e. swap count is 0 AND > > Do you mean moving all swap slots free to bypass the swap slot cache, eve= n it > is not from zswap? That might have unwanted side effects. The swap > slot cache is not just for swap files on disk. The batching has the > effect that on average lower cost of freeing per entry. Not bypassing the swap slot cache, just make the callbacks to invalidate the zswap entry, do memg uncharging, etc when the slot is no longer used and is entering the swap slot cache (i.e. when free_swap_slot() is called), instead of when draining the swap slot cache (i.e. when swap_range_free() is called). For all parts of MM outside of swap, the swap entry is freed when free_swap_slot() is called. We don't free it immediately because of caching, but this should be transparent to other parts of MM (e.g. zswap, memcg, etc). > > > not in the swap cache), all the hooks should be called (memcg, zswap, > > arch, ..) as the swap entry is effectively freed. The fact that > > swapfile code internally batches and caches slots should be > > transparent to other parts of MM. I am not sure if the calls can just > > be moved or if there are underlying assumptions in the implementation > > that would be broken, but it feels like the right thing to do. > > There is also the behavior that if the page gets swapped in but hasn't > changed, when swap out again, it is possible to avoid writing the > page again to the disk. For disk there is no overhead keeping the old > date on the disk not to touch it. For zpool it might have memory > overhead holding the compressed pool. The trade off might be > different. > > Chris