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 A2027C07548 for ; Wed, 15 Nov 2023 12:12:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C1A7A6B02FE; Wed, 15 Nov 2023 07:12:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BCA976B0303; Wed, 15 Nov 2023 07:12:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A91F66B0308; Wed, 15 Nov 2023 07:12:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9A84B6B02FE for ; Wed, 15 Nov 2023 07:12:18 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6B598160178 for ; Wed, 15 Nov 2023 12:12:18 +0000 (UTC) X-FDA: 81460075956.08.B0BD0F0 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf05.hostedemail.com (Postfix) with ESMTP id 9F5CA100009 for ; Wed, 15 Nov 2023 12:12:15 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=QafLW1RN; spf=pass (imf05.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700050336; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=T89SiAsQc/h+GMq70kagyYYGnBW+TAITQk5Fhw20c4w=; b=WlPiISaqwsrT+TKU6lLUyFBb4BP2JNKNgPEaBjOEEqFlrM+q0IIpzA4U3zPaa6bGnzS+d0 dh70o12X0SbpaKpFJA9YIru5KTMfqOJHQoMCy07+5Ll0dqIUbE/bYfVNTIwCnx+tadknGP Nk8A2Id5weD/3nwkLDf8imIe1CKEGO0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700050336; a=rsa-sha256; cv=none; b=gu6sms9Fq+SCvZawrXscyW1EU0GtGFZB102Ej6CpIfSvkRp82tqTpIVjWVXJQzqDBpNzsZ g0p/R+0hFVeP+VcsBNQU/mcmHguwTnQEVS5uRAta87jiXhvtBt/yWfqRQAIDFcjL3c/djV TvMcRH+xuicBsbzkPSZwJ0SH72PYgEY= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=QafLW1RN; spf=pass (imf05.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-50970c2115eso9436590e87.1 for ; Wed, 15 Nov 2023 04:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1700050333; x=1700655133; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=T89SiAsQc/h+GMq70kagyYYGnBW+TAITQk5Fhw20c4w=; b=QafLW1RNFU98r8M14b1//p4xa0LqxzcOUJEN8HEX1DVo3GIEgr3kPhbDp0JWBHTxmO hLAIzs6XKFErEn52I5Df9/OMkTNmRDasVA8cnusHorm4orzj4X5PT8BipCNU4ywGZPax vAhKxqcQGChUCP41EpZ5BOcT/CPhWw8aqt00p337fsx3wQYAh1qZaVeq0FgFbFi1RH5g dXHTRYvHJClnu6j80bmoTia5cSpObfLFyOpH20ss9WPqqULPXJScyjVTSs/mGE/7/awv TF6Tqq+pK0qGIY7XJdlwrQ6OSZjlVWJ0QztnRzkOgljfcmpv00v+cBcVzK+hk/6SK6Cx C17w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700050333; x=1700655133; h=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=T89SiAsQc/h+GMq70kagyYYGnBW+TAITQk5Fhw20c4w=; b=fKbkdoVXRWM7eNKlcRRoIo7kXqqOVBCsxw0cyl2zezTVPzbDDqJxji3x6ayl3T/YDe XTBpV8o65Q4olOjFBGp3vN2EwbKM7KPiKjA4zCgIzZn+HuMMgfXUDXOUR9+OhxKAtXs0 q56bL2mUPSGLGl1smq/eqJQk2/sAKkFdQkPgrEIG+RlfO7XJ0//ezmgJcQyZzkCKmdS6 rAuEMDr3fK9pI7JE8xXYqTtmWvvOuKGi3WwKo2jkZKTr2gmPYrQodD/AZI7qmUL10J2e pBHqBcikxvBTtYzRzscHg6qUDai4I8L1CwRa1YHKKl1/PMzSYJ3Ojy1wVzrU520mAQLX A4zw== X-Gm-Message-State: AOJu0YyJBGC1GW7ko5Mg43HVgP1SCYJUDTPVUPYz6XFOMCT9s1Ktw6K2 LYysrzJpcj2iTqVAddQomK1rRpbG1wMjAH5DgYW3Ow== X-Google-Smtp-Source: AGHT+IF11gaQjEjEYaDdzVe9+XgV1z74FQXYQLBkepiDrbrqLeVAdGpGUJ7LQtBo4pSj/D2u0wvXBC9oF0VigHRMNeU= X-Received: by 2002:a05:6512:ac4:b0:507:a701:3206 with SMTP id n4-20020a0565120ac400b00507a7013206mr11019099lfu.49.1700050333546; Wed, 15 Nov 2023 04:12:13 -0800 (PST) MIME-Version: 1.0 References: <20231113130601.3350915-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: =?UTF-8?B?6LS65Lit5Z2k?= Date: Wed, 15 Nov 2023 20:12:01 +0800 Message-ID: Subject: Re: [External] Re: [PATCH] mm:zswap: fix zswap entry reclamation failure in two scenarios To: Nhat Pham Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, yosryahmed@google.com, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 9F5CA100009 X-Rspam-User: X-Stat-Signature: p3xptmpnf3uua8tpgtr1eedntbtq96gz X-Rspamd-Server: rspam03 X-HE-Tag: 1700050335-983380 X-HE-Meta: U2FsdGVkX1+2KyCUTKfaOw54YsHU0HxmlFbc1vxGjLi54Qhm+VQfeD+gpBd2z0vuvoMzSg1TR9envxATnI6eTGDXtgOJ2DRKwYsVoTFQhbQz/A79BtZxq47G4GCE+BKxlOuhx5l+Exxt+5xFK9rFHeuyD5BYcYKz+zp103wOwrLJ/OU2my6Enc+R02nJEzZplBQiYbgWimB+I8TcIeJf5J7xquW4Gn0PZhBK0qyIXtM2wlFwjtfn8LjbRF0ykgZpigH4KIu/1YIErY+By8envYaV+KR1clHbekyeTPjytS4QBB8ZviJe6tV4fw75H3kIAnpvXnz2Aieu5JSZ6/DjcG+GGWakYhfB6l3vKhGcINC56KJ/s1twkocUMdp84jo/MUZDud2Ckdg67FvOdOWRxiSGOPgtmcFAYdeIwe5PVaehZK2jj3FKzX+JHfwUDm9hT53p4m9joCExhBzAv9ea/3rWLE6p4Ux2ZP+MtOjK6qEJQlJ7V6ON35ZB9VNqJ840Vm4R+olvZNe+dKzlHoN/yPMkrMasp/dDYVm1I4D6Thj+okOfwLHmkP34QXjVSSdOxdm879LeOUB0I8DV+XeS6IJXUALNDPt7JV1G5I54E9PP/+vxwAwrrF9OAAJtYvu7EL0Omllo8gnmr9sQcGGto4V9FPRCJB7590LJdw5D8TM06T4HxkRYMu/M327q396OLPCh1UeiecgHKdBCXhzGcXbEMsxzJNoJ8mSkr1tbJzk/29gjQjBgYKz/SsBTfYYv1IwKqevUjhkCZtdcfNtcNiRfHBreygAIpm8/17LWVlrmGl9G8g40IweErKHu31dWRdMJJU2WRhd4VG/XYY2D1ex3b75XL11i7i6auZD6u1Y14jF7ri9aaPOVjGXf+QlGKPibNDppBYf0tuwfY/XAYMBmALrtEfRnDotbGRv7y2121m/sUXsCcxQTKk1H5vkOc7OaLjmS0n4HgYqsi39 sDs9RIRX unqns6FspZugf/buM1Vccld8V41p5o+8HWEVPNkbPCxqUba5bvbR+FjrcJCrZ3v7S12zZ1s3v33CVS0bBic7wLw1/zsbAoOxqwSXoQ/TI9cgaVeRoYl179LKQ3kifyuwwQD79GSS0HZE4pCjwqxrEQbkz/ufSnhLWrzId0R0xh5bJAxes6mnDgEHz+ItGxIRVXFE+o29IrvZiawc2IehpmOFej39pHONYZJ0hVlDhL2A5vzcYXxgcSpDjUb5dsX/KyhnmCoFECeVLWA/1jPXc1VlZsAwwkldtXo3g X-Bogosity: Ham, tests=bogofilter, spamicity=0.000102, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > > Ah my bad, I should have been clearer. > > I was looking at the zswap shrinker patch series (specifically the > cgroup-aware LRU patch), which moves the counter update out of > zswap_writeback_entry. If we apply that patch on top of that series, we will > screw up the counter. Should be easily fixable anyway though. Got it. > > Ah I think I understand the point of the patch a bit better now. > > Essentially, we're invalidating these entries, which does reclaim the > memory used for these compressed objects, but there is no IO involved. > Writeback-less shrinking, if you will. > > This will still screw up one of the heuristics I'm using for the zswap > shrinker a bit, but that should be easily fixable with some plumbing. > Same goes for the writeback counter - but depending on the order in > which Andrew apply the patches, you might have to resolve the conflicts > there :) OK, I will fix it. > > Other than this objection, I think this optimization makes sense to me: > > In the first case, we already freed the swap entry. Might as well also > dropped the zswap entry. > > In the second case, we already have another copy in memory, so > dropping the compressed copy to make space for warmer objects > coming into zswap makes sense to me. Might be worth doing a > micro-benchmark to verify this intuition, but I agree that it's more > important to maintain the LRU ordering than any CPU saving from > skipping re-compression. > > I would suggest that you should expand on this on the commit log > to make clearer the motivation behind this optimization, if you were > to re-submit this patch for some reason (for e.g to resolve the > aforementioned conflicts with the zswap shrinker series). > > But otherwise, LGTM! > > Feel free to add the following tag: > Reviewed-by: Nhat Pham Thanks, there are still some commits from Yosry, after that, I will send it again.