Received: by 2002:a05:7412:b130:b0:e2:908c:2ebd with SMTP id az48csp77404rdb; Thu, 16 Nov 2023 12:19:36 -0800 (PST) X-Google-Smtp-Source: AGHT+IG3NG2p72VvjV9GELtNnhKQXM0KYJJIOYvHEv5fVkibBqN0ZrhHOInwWMw5ZOL3asAdxo4B X-Received: by 2002:a17:90b:4d09:b0:280:2406:7021 with SMTP id mw9-20020a17090b4d0900b0028024067021mr17936128pjb.35.1700165976095; Thu, 16 Nov 2023 12:19:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700165976; cv=none; d=google.com; s=arc-20160816; b=O+zHkT6P5KpCbI6twhuaw/tg3McQkjUAcn8bJvMCLqpQVqIA4vFF6ZoAPEOY/Ak+7r KxS1kv4ycg2Zv5AxurHDf46S3Sv/DRzpg3U88MDdmRtwGzcpBiNW+5iv7y+ImdQkGGlE WJ3kuG2NP70F5GWIseYFV+U4V6X1dUWqREPv2jheHmKeFYQBmBa13geVevmCCPEt9LxC D/nn8EYLY/jGhPHYBekWrIZb9R7QUUijfbcWwiMkBJGClO0xSpRuWqC71jUf8Jl/GlOU 1wSqmXwukfJ7lyRkpR+JZtaHoLmaqQTXdTcWQ1k0ToPe+QMKi5IM/OLX8vbpLGZ22AAt nL8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=1OgdBdxfhNkPsuCj3CVQO+gy86aXcSm+tfVyfjz90gM=; fh=0CCe9/9e032Cit5U6Bdq2LlIGvkLW6NVwvKvbKpGgC8=; b=Dizh+X4EHTTVBskp4z/h9Uv/QC61YSxKMDAXW/uYYAzPFJz/dD9AnS2+dGeXOqBRJ1 sRtFMEKgUSBlXJrXAOs5R/CnGtTisGBg/3jlrm2rwOS0vHGQjRHRBwn6LU6FAuUgrG7M NKLrW8TLozOqClpZL/m3O9LSffou3XOJq711QRjI6blvT9/qZAcP88NOnu1B9Fv/lfsM 0bft5BQ/ewy6sdE1WEoBErzcP87/xeRvTjGl8zQApd+enYL1tq0fctHPibWMN4z9NNqW YVPQfivrYUZSNyfwCKd7sh41Yi0L2h0JzY9S+9TDh8OvLLq084H/b9bHR1hOzyjzeLhv Ed7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=X4fc+4lG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id pf1-20020a17090b1d8100b002800879f482si2857955pjb.87.2023.11.16.12.19.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Nov 2023 12:19:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=X4fc+4lG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 0379781DE3A4; Thu, 16 Nov 2023 12:19:30 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229510AbjKPUTX (ORCPT + 99 others); Thu, 16 Nov 2023 15:19:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229464AbjKPUTW (ORCPT ); Thu, 16 Nov 2023 15:19:22 -0500 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D829126 for ; Thu, 16 Nov 2023 12:19:19 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-9e62ab773f1so180064866b.0 for ; Thu, 16 Nov 2023 12:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1700165958; x=1700770758; darn=vger.kernel.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=X4fc+4lGrv+8VqLjAKVWjzkLP4rMdoPCnIJ/Sy4lQONkcfRMYeNy8cu7lKocJHchcI O4Q75ChBATgCpDz1LbDD3kYdtAnLhAMnOyYikdJphalGZZiGjIhuHcQfvJywqXarwOKp AO8yIe2Ltv9iMDZGkLy4ktiNwnJgBtZNyHIONfpxpEki45UGskR6oyz40Pb2W/ijMJKk iVYGzZgA0qgn4iJuSdpJ6150XXc4axSd3fmwMJ8y3+4cGc/p8XmsCRdvyoo5JFcWzF4y ZeihuxCMyc1nVt0JF6+3yI7HJfC3QuD8HsEQXR+d22MBwqel8lO7aRltqyIXLlSCsrxg QNjg== 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=xKYRtQ/rOSe2nmisMby4VgpXnnQ33oIN34qw/0qhvqSM5JT62f/iHKrX5w+n9cCURv m2fObckiPjGkwwiKoCozKk2ha1OXgnkN+u10IE2MJSm3Uiky+xGpvWQ5aL3EMid7tXOR +fGrdBj1xzcZi3lmC5vvxvWiNarlqVLLwaUNt9KQOvUs9daCFkvvEe81iePDGvxcH6AJ T+4Imf+NHGp+sEJxz0zJurQQlEIAkZQxXlPvCxEU/NwQRvM+OPJHA3TvzYuKKfAYpYSH StnBXNYT3yoNfq0gM2ikyTfJ1iIsOVI7enLAJ/d6CfkDSXnpS7kmcA5tngZ+HB/vJ+NH 4LSA== X-Gm-Message-State: AOJu0Yz20SwUeTp/XM+qkDW4uwgyFN/1GH1sf22RmAaSpHglTbCipjiH KjbNeAWHKrWLJFUSdwV8XZ5AegMXIv4AFKuqMVVvsg== 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-Spam-Status: No, score=-8.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Thu, 16 Nov 2023 12:19:30 -0800 (PST) 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