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 21611CDB46E for ; Thu, 12 Oct 2023 14:13:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E57A8D012C; Thu, 12 Oct 2023 10:13:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 894F48D0002; Thu, 12 Oct 2023 10:13:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7847F8D012C; Thu, 12 Oct 2023 10:13:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 64C0F8D0002 for ; Thu, 12 Oct 2023 10:13:33 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 15BFC160643 for ; Thu, 12 Oct 2023 14:13:33 +0000 (UTC) X-FDA: 81337002306.11.C6AD4B0 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf01.hostedemail.com (Postfix) with ESMTP id 69CF840015 for ; Thu, 12 Oct 2023 14:13:30 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=LptxateE; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf01.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697120011; 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=XK+AWSsQ2H33A1L6bytZOXVSGoyHWqpSkicQBPY+zcE=; b=4kFgp1GjTNMBBqTQXOTeGjtUwEBoeOWIdnUCgkHfARNolQe97g1jh39CcEFO8gUNgyWkaG gg713hACR0S1lsaBAHYqRcoju6XhuOmgggXlZT1tAPKDGPrk7FfqY5Gr1QqzNssV9qvEyC NkWR3vnweULPyxSFrnBBcc2cledajr4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=LptxateE; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf01.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697120011; a=rsa-sha256; cv=none; b=SDEEGYXE9fjMj/eRs3DNEPxJ/idSZ/tA9kVoDhkBtw13PggRUyk32tr4nwNsgNYf6nkxI8 aGCcwmS39kAhQjzk4XCJM9MCq0vZ0/T8x2n5MrZzaNPyVeyRsmZK4QAvvc/gG3SKjpJkIp 3sq0iX88Ura/u1PgAXtYXXMnjCovPVI= Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-50437c618b4so1315408e87.2 for ; Thu, 12 Oct 2023 07:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1697120008; x=1697724808; 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=XK+AWSsQ2H33A1L6bytZOXVSGoyHWqpSkicQBPY+zcE=; b=LptxateEm20s75k+2OE6I8ikabUl+QldH5XE/51KnGprOSI4XRgH+b0qofFpPT056R OR9hcOC2CMdhD5yJ2nXvtU2RvNRxOJOf/Nqa9cjedbH5nza2xpf29yYI/pF734uR9iSm U9zenQ8kBuOc4wuUCYuRwKGC9S3PUxBm/76lGhSgB89lPhMYFf+rAkURcI3/ngsLqVLP jGS4VfZle2nQfxtkQATGNXcv8/XDZB5W1EVth7fUmvTr/pXhY9cq7VMotULh7i4a2Edj FOWcohN3dLL2pPNoxAM8RZHrRla1Tn7BHrtRSna/6BzjbmxfMr43mxsGsfDJAsvdXHni 2tOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697120008; x=1697724808; 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=XK+AWSsQ2H33A1L6bytZOXVSGoyHWqpSkicQBPY+zcE=; b=kNijNCji+khOWRU9BRoOWyopdx1z0E5RSmOPUy3dOc3kxSyHqJTk5zV0v1kEKaCFAn EIJbdcdd5v9UIXOWxNYd2Knf6psLRY+CMslZ3TG+nqyl0W1qKBDukzJ81vav3qzvRa2y Wj1bZnVwVhI09kQCinZl7w5vokeYjW39uV49ZGIEidjP/dDvzFClVA5XTGEDSVvY+b4X 57fUJsIMT/TZ8vlr1UI5nvFW2A6FRTygQUEIYiIJ/x0JI1t7u7tIfr9HZQAhFy/eZDYl BbGKdr1VF8onoNFLftrmspr7eerlzin83m1nsfvYK5qdcnDLNao+YWgBxBW4AfCG4viD kWfQ== X-Gm-Message-State: AOJu0Yxubhv0JSNK9r1k/SjkmnftewxG8zIbWHSqpXklUHSDvLqSqFTo IkwpZAbIp4X2OTSlLWrnm1tQV6JjMSzoEz0MS5uFCA== X-Google-Smtp-Source: AGHT+IEW8LIlJF+IkYg1FO+B3C5kxp9FpL15COCm5jVowYGJmAblgTumAbou3m74W4CMu7tujdudQ+0HT4xU0N0/Y8Q= X-Received: by 2002:a19:f015:0:b0:500:9dd4:2969 with SMTP id p21-20020a19f015000000b005009dd42969mr18161152lfc.59.1697120008183; Thu, 12 Oct 2023 07:13:28 -0700 (PDT) MIME-Version: 1.0 References: <20231011051117.2289518-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: =?UTF-8?B?6LS65Lit5Z2k?= Date: Thu, 12 Oct 2023 22:13:16 +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: 69CF840015 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: m5q5jrpm6yzeitaws6rttyqu374xrzd7 X-HE-Tag: 1697120010-636155 X-HE-Meta: U2FsdGVkX1+/yQweoh/HVso2WL8/YQ3r3i/2DWkWSh4Ii8x1v503g+U3hXkpPl5HO5oUk8X4OrIbjEQyP6BCO68K0D/QTy+STwfEfhQbYbSJA4lcMCrX5k9GkeVZhOZnf07IMn4mZzbrzqb7apQOwHLCVuLmV7Dz4rmsAV72EQNnMsydxJ70voDR3go8Kmc/sIBEMjxYt9Z/HO6yI9rSKmBkFWNCnGLriQcOPAoGiRYXGEUUvENIYCluI53tWcFqQbLNLP8N9PuYu/i3vvr4bHyp+0m7ynXNeRTzUnqCEO1OhbBAMe0s00vXlTzf9qDHEl/UnSv+ZcjnGMly0T12w9B42Cy15CcK/VB5BAt3nTJ0mrQpl9V5c3aedk22FmogvqENqkReKy5QheLY1OKrykiMmba45KBCHSDpw0n3W1hF9g8NeFHAZtT3weOHgeraIO1CMVD8XhAeeEFVA7HFrEbmKjEGuid4bqgKWC303bGSrPlNrvBXJ+prSe6nUmVPlOqMoGdjm5eQaampGdgFrFHCngXMO4RlfQbAdUeW5/kjf8DP7TJfduCe5vN2eTZ67TxQR99xDZ9OIDFxUCJZWW85ubGNSBo7j54zg0PddlwBI2i1JrCA9LzI0vSJeEDKlWBs0amCfxmjPt9bpjlTx9MgwVFYRYEpirO8/XlnVPsI3amGsAT/TpT3s11qDcBflaE5eMwE7AkEckNv/MHbT0iAmuemI0As0kaohkZU85uNHPu//k+MyObAvBc1SFYDJM84HSPPea3PHyw9zRHL4sLiUHsgCJhb4s1M9wfTA3wNSPJaPHx9Wz9g8kSJOGYhKbi1gFogI+fnz4gkm3cz1U7qzgORpWNM9SeSb3GEZDMnK6/Ee8OSjS4Q/p2OV252mC95o7PMW9c5DbZplNvPs0Pke8qWcO69PSNrVE2hrSwyKR56mTkOJ25A8BEQHf0DW+pQygXjQneyqcx6Pv/ mBGhWPae nqRMqqI0AM92Al6LZ49eb4/AFPGkRTAnTx+jpse0RQbSEg71r7l3K34SUO76TGdARkw0CMhuUNAUW+yBLsx+W2u8Sn0Da61paPdJO9gY90OZftRrStuFYV1y1UPNVKtq7PisphX4qVHS5k6HYkxD1rBjVgNEzOAR37Wvv/TL+8jHwxELuF8WMYuUZDxrRvR5NMaCHsjmsd2UAaaZgFzmqFnsWo+jQ3nJMjhYAs8lAdsy99RGUSshDx3scvy+ZfcpEGvig+/M+qQvocXlCGp0274rikxKWK1gg56eoWEiGeyq+5OBs5ygMCWslnaS/XB+EdieTUyiMQ4qGwA8Rl+5qTyFi7q1jxManIwY78JVrLeQ6ejCwlANMC0GDLHXW09eyb5CjRkStQps2pjZp3Hn+q1MQLw5t7+R/Dyrc 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: Hi Nhat, thanks for your detailed reply. > We're currently trying to solve this exact problem. Our approach is to > add a shrinker that automatically shrinks the size of the zswap pool: > > https://lore.kernel.org/lkml/20230919171447.2712746-1-nphamcs@gmail.com/ > > It is triggered on memory-pressure, and can perform reclaim in a > workload-specific manner. > > I'm currently working on v3 of this patch series, but in the meantime, > could you take a look and see if it will address your issues as well? > > Comments and suggestions are always welcome, of course :) > Thanks, I've seen both patches. But we hope to be able to reclaim memory in advance, regardless of memory pressure, like memory.reclaim in memcg, so we can offload memory in different tiers. > > My concern with this approach is that this value seems rather arbitrary. > I imagine that it is workload- and memory access pattern- dependent, > and will have to be tuned. Other than a couple of big users, no one > will have the resources to do this. > > And since this is a one-off knob, there's another parameter users > will have to decide - frequency, i.e how often should the userspace > agent trigger this reclaim action. This is again very hard to determine > a priori, and most likely has to be tuned as well. > I totally agree with you, this is the key point of this approach.It depends on how we define cold pages, which are usually measured in time, such as not being accessed for 600 seconds, etc. So the frequency should be greater than 600 seconds. > I think there might be some issues with just storing the store time here > as well. IIUC, there might be cases where the zswap entry > is accessed and brought into memory, but that entry (with the associated > compressed memory) still hangs around. For e.g and more context, > see this patch that enables exclusive loads: > > https://lore.kernel.org/lkml/20230607195143.1473802-1-yosryahmed@google.c= om/ > > If that happens, this sto_time field does not tell the full story, right? > For instance, if an object is stored a long time ago, but has been > accessed since, it shouldn't be considered a cold object that should be > a candidate for reclaim. But the old sto_time would indicate otherwise. > Thanks for your review=EF=BC=8Cwe should update the store time when it was = loaded. But it confused me, there are two copies of the same page in memory (compressed and uncompressed) after faulting in a page from zswap if 'zswap_exclusive_loads_enabled' was disabled. I didn't notice any differenc= e when turning that option on or off because the frontswap_ops has been remov= ed and there is no frontswap_map anymore. Sorry, am I missing something?