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 8AB22CDB47E for ; Fri, 13 Oct 2023 13:38:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 07C0B80017; Fri, 13 Oct 2023 09:38:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 02D2C8D0015; Fri, 13 Oct 2023 09:38:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E355280017; Fri, 13 Oct 2023 09:38:24 -0400 (EDT) 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 D09568D0015 for ; Fri, 13 Oct 2023 09:38:24 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A02AFC02EA for ; Fri, 13 Oct 2023 13:38:24 +0000 (UTC) X-FDA: 81340542528.21.9E28A99 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf14.hostedemail.com (Postfix) with ESMTP id 8F474100030 for ; Fri, 13 Oct 2023 13:38:21 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=i1KkkeFq; spf=pass (imf14.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.41 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=1697204302; 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=qr3E/uN8pNJ2Tl7rBw3tcz06mz6kFhL5wHJ5Z55gU3s=; b=KAkp3XLwDhldomm0ac5cmsweUZZnez19eqngoYZchObJUNgKR7gFfFa493yOrF3Fe7vkNu QIG6g7GI4ua6WEAPRTuJnMvzRpfUiPr5pwLmJ6TtuscWEAXkwEDE4kyvAoZfxSVyYnp4VQ 9JgygyHpCovLf4LcXdVHgmNpogs883U= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697204302; a=rsa-sha256; cv=none; b=wXkFd2sbBxws8ktgQNov39jRhI12cdndKbZX4afOzjfAXkJGpqXjejOqDYAAwWzMC+OhL/ qrVAPXzZSkwgk79FPdwcbct/JiWgwl8E4PoSY4p2kFdYK1wbfjdEY8vSKR2ic/KOie1rXo RrawRWYqMOoK1RMJI4l1AZ9FsSW2NIU= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=i1KkkeFq; spf=pass (imf14.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-50481a0eee7so3894163e87.0 for ; Fri, 13 Oct 2023 06:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1697204299; x=1697809099; 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=qr3E/uN8pNJ2Tl7rBw3tcz06mz6kFhL5wHJ5Z55gU3s=; b=i1KkkeFq18i3ZwFOwQ+Ct/uI77+YT812jgC6LVUGU4Nc4QSWef3j/PbElxCVWN5CrV xC28e4PU0Qfi3l1ERBVkMdHLdjMo111KwDLD4fhz5IKtXbwrp+PTbR+hoDHaIhqI4XuW txIHpeGnH0Rj5WGrLfrbE+UFYg8/dSjyJH7cf6CVgHYy5eRApYeG4H+/++RAWE40XMh9 dOHZWUKO6sJi3G/eh5M3yH+njI2FC8e2EA9WZIjgB1BR14mzyNXpxC2mheCTs0NipLlB k9/dTxLsSoh0Dn+CMhsTgr27zZHJJmGXOJ5uoM5tBzl2kDU7C3VtZjNFijMV0VM2TDnw JmAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697204299; x=1697809099; 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=qr3E/uN8pNJ2Tl7rBw3tcz06mz6kFhL5wHJ5Z55gU3s=; b=ehfMWCS9LuXljridZBtowEneppi4lCs5QbiLAezAz2aoTRi/kk/f8VIjQ0aIP0nxiJ awEHR/ZSMQ5c2dmFUziMCoJJchFg8nshghVjobaMhHjxEyrr7LtdQNZUoxVnf8sXtYli YzGx2ZnCfr8KbuPYxX257VMPDivRyrANJgrD5aqJPpXdJeQex5lxi4VxWziJe7UTzhWH GFXOvY1458wrFt0KAOGWsIM1TanYPQtpTp30/mwe3RJWT9OMTjLdad2Mzw6V/CImyL+Y 4vX9dflWTxfVh8mqe3odVwkOofawFHI1fThM/BTFdD+M+MLJNkod4kuP8nLiHUJYdpTI wWlA== X-Gm-Message-State: AOJu0Yy5PUTaFwN3nqkRnnWn6kQ1/Zjx7mO/uK25g4ii2g11qTRBkatS tMEtiTGSycY4kG3qe3h/FsDeVG8K6xHR5ud/+yfOkw== X-Google-Smtp-Source: AGHT+IHa8fvsa6suyV63dmf8+FA9YHAAh+rAXfMlRc/PLDXmWAIZONkhLVjCj1dNi3erb0QveuA4UTO1oX8xqMYaYB0= X-Received: by 2002:a05:6512:3da3:b0:501:bf37:1fb3 with SMTP id k35-20020a0565123da300b00501bf371fb3mr123610lfv.24.1697204299525; Fri, 13 Oct 2023 06:38:19 -0700 (PDT) MIME-Version: 1.0 References: <20231011051117.2289518-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: =?UTF-8?B?6LS65Lit5Z2k?= Date: Fri, 13 Oct 2023 21:38:07 +0800 Message-ID: Subject: Re: [External] Re: [RFC PATCH] zswap: add writeback_time_threshold interface to shrink zswap pool 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" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 8F474100030 X-Rspam-User: X-Stat-Signature: 8asxwprcqm3imtnahguaibbibenf17d8 X-Rspamd-Server: rspam03 X-HE-Tag: 1697204301-64327 X-HE-Meta: U2FsdGVkX193RX8N6yCeTOT9hbKVdlmpRmIdp5QITPpfyBziStJV+aahjtrFu1W4TDNwCwdCEyXEfHoSpFOtesz1dzGsDyjvOVqBgZlrP7fFkfChKghOM/f8tpW/+ZGbY9i4EJengz7x7YNpqV7kuZuIKf8oVKrayASZ69pMX/QrMmr5O52ulWrPOBUPQYErmp6/AmZC4FZS0xaH3YY93LByd/1cVQdsx1a5CQDn0qKCwExIRJbMi9YhTBMLYzQvZr7uFzphyRTvWnhNJw9wEi5jXOY8nsMghGgSEHZpKEONdBHISTgiX3jke2E0WHqSGcxhEhtzT3J3GQwOnDIKQr0hKHydX/+6ZBVMZkrm4re7xx/DIAwKzsIsqtZiVvOlrcSp6YC96DcOfoBNuLnn1SQKdl4npkOSnXqa2CLUULUrVkTxXXTSYGYGgypaK40go4e4+DZyCMggGGECPN+oqWTUtA9Ea+yJAvRQIxcdUX2yLl1gryJOKBl0NsFRfXRCFb2H6/lRoDK6b8yn+RESMmARe6Wg6y2T2HAQPA45tJ58slEI0GcInmEVmhS1UOzLjbit+YMVet2WFnIyQByuajkubM+M+AbcuBfengySex/DelURdRgX7BptttlPOZBX2M1aa0aDXh6K+GcmHeNcFCICbWKQzT9mF3M4gYbfNAo6SuZ29ZlBkFIh0vycFW/lF5T8K8IzCaeGf7xMXSSPZN14q3XyFV+ujefG2/v1ZBn0cDiMAs/gT4rOPXPuUhNZb21imuRkLkGjj85BdekAYjW8yO7s1CBhoPuEXMAcIPnJyPxRwTtk1lZckrV3ino6kRTIYqvy05i4B/hB6P+RVp3ss+JAqeaGxsXdZVuzQUPdWH/NNmS1N8soVhHnvp/nkUhclMpKrMbXXTBD+AQ9Q9Pk1QEins7V3Tk24P4QmmzX6yxCfIThkpwuB4ObDx1YLoN/SRSLiUnPM1mgHZw KpUgDpWp jJOjnhxY3qoAu7pX8ybLFqDFFNm+BgiLFf1W26XOoq9cHLVaY2mf2RK5oAFmgFMCpLfQkrCU+swNbpgFlWPFNJ/0GDLWsQfP56cfkIJ7iSzLiptSkr8da2CQ6qDfAusdeA4o9Z/zp3hx2eamIEnU4FK6Cx5hLAUtJPy+Pi/xicw1sOfzASxAlCZx6QH0EbrqRWOp3KCgz2f1JTd2VSzcsWkilf8D/kW8WAOpiKBO8+JnIsIGJ1ieySDGribrjWnEF3iwPDA1V1b8TE9gLgrcg3eZot1uRUKg9DLrH/mb0XdLCaRLJWuaXOXKtfQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000018, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > > As Johannes pointed out, with a zswap shrinker, we can just push on > the memory.reclaim knob, and it'll automatically get pushed down the > pipeline: > > memory -> swap -> zswap > > That seems to be a bit more natural and user-friendly to me than > making the users manually decide to push zswap out to swap. > > My ideal vision of how all of this should go is that users provide an > abstract declaration of requirement, and the specific decision of what > to be done is left to the kernel to perform, as transparently to the user > as possible. This philosophy extends to multi-tier memory management > in general, not just the above 3-tier model. > That sounds great=EF=BC=8Ci will backport it and have a try. > > I guess my main concern here is - how do you determine the value > 600 seconds in the first place? > I will test based on different applications and corresponding memory access models. Usually we run similar programs on the same machine. First, we can use memory.reclaim to swap out pages to zswap, and with this patch , I would find the distribution of times the page resides in zswap, and then choose the appropriate time. > And yes, the frequency should be greater than the oldness cutoff, > but how much greater? > This depends on the user's memory needs. If you want to reclaim memory faster, you can set it to 1.5 times the threshold. On the contrary, you can set it to 1 hour, two hours, etc. > We can run experiments to decide what cutoff will hurt performance > the least (or improve the performance the most), but that value will > be specific to our workload and memory access patterns. Other > users might need a different value entirely, and they might not have > the resources to find out. > > If it's just a binary decision (on or off), then at least it could be > one A/B experiment (per workload/service). But the range here > could vary wildly. > > Is there at least a default value that works decently well across > workload/service, in your experience? > Yes I agree, it's difficult to set a perfect value, but it's actually benef= icial to just have a normal value, such as 600 seconds by default. This means that the zswap value stores values that have not been accessed within 600 seconds and then unloads them to swap. > I believe Johannes has explained the case where this could happen. > But yeah, this should be fixable with by updating the stored time > field on access (maybe rename it to something a bit more fitting as > well - last_accessed_time?) Thanks, I agree. > > Regardless, it is incredibly validating to see that other parties share t= he > same problems as us :) It's not a super invasive change as well. > I just don't think it solves the issue that well for every zswap user. I've noticed this problem before and thought about some solutions,but only saw your patch recently. I can also try it and discuss it together.At the same time, I will think about how to improve this patch.