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 C558BC47077 for ; Thu, 11 Jan 2024 03:49:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5AA416B009D; Wed, 10 Jan 2024 22:49:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 55A636B009E; Wed, 10 Jan 2024 22:49:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 421AA6B009F; Wed, 10 Jan 2024 22:49:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3294D6B009D for ; Wed, 10 Jan 2024 22:49:18 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 02946140424 for ; Thu, 11 Jan 2024 03:49:17 +0000 (UTC) X-FDA: 81665649996.02.6CF1505 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by imf06.hostedemail.com (Postfix) with ESMTP id 932D718000F for ; Thu, 11 Jan 2024 03:49:14 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=ayHHRJBM; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf06.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.54 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=1704944955; 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=ZREJaEipJctQbF5q1fL266eGmJzwCp7vTp7Y0bYWgKs=; b=iDgN/nREH1YZQ8HP3h1Hv/LW05Xh65ZRoytUMf9paVah0ZS+qiwjksV3yqTiGr/DX5+d85 VyL5QgWCX8lvpqDZ4jzuF0yxr+2BWs9ZLMQBeTwL4/RZJjOq7/dQaU0Baz+7p7XYIRGv9l nIKMYA05ALm3DfTvWZmAkPkqapUf4A8= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=ayHHRJBM; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf06.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.54 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704944955; a=rsa-sha256; cv=none; b=WaMf/N7V1HHY2yXobpV9X+XWDy5n3t/YgBcMiGRtMZXj06BEsEK+2C3g3NEy5vOBsGYBPO HWBSuNrN7DjuRlnrYriQKNN7/aHXEI6aPlG80fuALTQOjBRfYAnc5E1zzxjzdll0/xwBXI gCXmjlUtvdz3uHPSttCIlVBK5ubTTxI= Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-50e78f1f41fso5078532e87.2 for ; Wed, 10 Jan 2024 19:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1704944952; x=1705549752; 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=ZREJaEipJctQbF5q1fL266eGmJzwCp7vTp7Y0bYWgKs=; b=ayHHRJBMcGror2qIx3VrfS0qjEsCrvQHlXFL/b39uV+egkB5ZAmUQ2hPEkYCwcFCIG qg3+NvCtfNg7rr03acawIIHBP07tXO+t3nTQRz5E3PHNLe0Ma8ulzIVRf3ISEemzyGJl Evod+9DnZ8Q4QjgTFYDZhpzUHrH6NwPpB1Hdtcw+4SK0GdCYBGA7LySOEW3LeVqah5Wq Tda74J3/V9pJOXWFgD4yQv/1vrVh3Ig+c0l1xdEgzmT/kXfKplHaJs8xpquvKLUAjyTQ jruFYt7wJ16HjWaij77s2zXclgEbZjrJQhxNcsusT/C1b3pPM1lv1uE+w4I4HUmxVj2G 8Ecw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704944952; x=1705549752; 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=ZREJaEipJctQbF5q1fL266eGmJzwCp7vTp7Y0bYWgKs=; b=Gwiy3/wY5podwu6vYclkwGdYZM8p9ugyY4HmQ7z1h+5Wb+XIEPLdvnSUfoPkM3rAmA Ww8Zu8KoAy8h+Nx6Z3lsxGKCeNvBXlV2Q6UcouBgkuSm5isVk5E/GJ0ZZCqy+A3bbEj6 mZriA1v6IlgezEHAktuD5MtA16N3G6mf22Ik0SMqk8TSVxwPnfX417UClJSCw/yOCE37 jnQL/hR35s3n6IXYPhVikVjqhB0am90eMGalGGQ4kRyPJBy1yYglp4nlTwiIDJPW9Bff 99qkDt8FNqG8LxXWZQAYEui44IJQw3Iv3AL3gfuLhAwp12Sut/DStYshGMgnA9EC9Qcu YWwQ== X-Gm-Message-State: AOJu0YwvD4FPie2h1Tzj/f+FFTcvPBqwLfqJk4IDM+uzLqIhNMs4wSdL EhBTp9vpDfUdM7Q7K9wiOgAnPmlRkomSp0tXPCtpjYSu74UFWw== X-Google-Smtp-Source: AGHT+IGF/3shiovL5bt+rCGdeEdmFeHXR7K8Bzf+732rRzXi7LpsYPdt13D1R5ynHAuFB3WFkd9IcNYYKQ+zbPVbC7I= X-Received: by 2002:a05:6512:3041:b0:50e:9ba0:5e20 with SMTP id b1-20020a056512304100b0050e9ba05e20mr212864lfb.99.1704944952651; Wed, 10 Jan 2024 19:49:12 -0800 (PST) MIME-Version: 1.0 References: <20231024142706.195517-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Zhongkun He Date: Thu, 11 Jan 2024 11:48:59 +0800 Message-ID: Subject: Re: [External] Re: [PATCH] mm: zswap: fix the lack of page lru flag in zswap_writeback_entry To: Nhat Pham Cc: Yosry Ahmed , akpm@linux-foundation.org, hannes@cmpxchg.org, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Chris Li Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: xsyb4nis8e5zwq4bncoep9meggn4pd9i X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 932D718000F X-HE-Tag: 1704944954-591984 X-HE-Meta: U2FsdGVkX18sagFKOi9vvvT5MZgCHxo9Q7mpdeiL5s+pMvzYqswupuISMYBHZUKhNtyGkGXs0FiZXk+bAbImvJ9kuNKdHY1bcoRYIP6PnVAn681l1ToHBE6Le4dq4pTXZG1Uuv2KYAux5rg8N/Y6yaFFjTBoIxeyqkj+gjfX+U88ax1cRjKueb99L9sBETXaVXeW3NWzXIk6pozMM2jg5QCVAuU3hglgLgLx4HffnDQsbeR/9O54PFaUCauCug1kcnrxD86od1Ju/dC49DhDjA1c6H7mGYZgJDO5KzH6uX6H/kO5UkSKwiCF0i1qNhr/WweovoRJxxGdtTZ59K/hWVHn+M6pDFNGhMAqsPWRkfhHgjXFcPaVn4iIluWQzUrAK1j/JgEZGkMlNToF787VYZmi68SWhBaao/XRGqWARlTPi4Wlzr87FX9iSZCpw0IXjxjysdN6qmVMF9HnxNrZcajzJT5hus/6cs9bEOsXFvUMRNrPJr0AgR9AgDBNAfJ/+A0atf2Up2J60og/V4yzDIrRovPEFadhzoJcH5NIgBtPE4S0W/j0TPSJNpJB9mZbEs/xuDPxbMeV87y7zOIalG7ZdNE/ukU88UljgO8JIn6eS4vzQKjxsF4xpEbadhSIcHgCQfI3in6QiLfcXJynX+GBld7CA+hp/jloTglmNbPLIdjzue+XzXyvHENgXg9sP+VISbxJ9exhoCuxbyh5DjNMzaj60UVXjP0okCPAMNvFLJUc42892aQS8cRuOykqD/2E0tWmermRZKTJ2j+CT+UgxUhloHqcUg5NN2gfkCG3HMMlzcBDBuY6MJnDkqYVDlf+VcXH3gqUeN5HKPWk4HRs+s6u6Q5EJ7Qu1ZEv/EOTiSWrzg0s53YDTA5S/juJ9hfr1IX1QURiVoF6pAk8rBshXwCY1SjJZg0f9knP2Ksb8sOgqzkr4WKrNNWopqwAy04tWNptPCIZITuvRMI 1b7Xt+yR CzglKJy9RiI3aYItPRVOrQWvH9ms+9joqcgRytU/Qaw+31Zt5wVrcQ3mRVg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > > This sounds dangerous. This is going to introduce a rather large > unexpected side effect - we're changing the readahead behavior in a > seemingly small zswap optimization. In fact, I'd argue that if we do > this, the readahead behavior change will be the "main effect", and the > zswap-side change would be a "happy consequence". We should run a lot > of benchmarking and document the change extensively if we pursue this > route. > I agree with the unexpected side effect, and here I need to clarify the original intention of this patch.Please see the memory offloading steps below. memory zswap(reclaim) memory+swap (writeback) 1G 0.5G 1G(tmp memory) + 1G=EF=BC=88= swap=EF=BC=89 If the decompressed memory cannot be released in time, zswap's writeback has great side effects(mostly clod pages). On the one hand, the memory space has not been reduced, but has increased (from 0.5G->1G). At the same time, it is not put the pages to the tail of the lru. When the memory is insufficient, other pages will be squeezed out and released early. With this patch=EF=BC=8C we can put the tmp pages to the tail and reclaim i= t in time when the memory is insufficient or actively reclaimed. So I think this patch makes sense and hope it can be fixed with a suitable approaches. > > Unless some page flag/readahead expert can confirm that the first > option is safe, my vote is on this option. I mean, it's fairly minimal > codewise, no? Just a bunch of plumbing. We can also keep the other > call sites intact if we just rename the old versions - something along > the line of: > > __read_swap_cache_async_head(..., bool add_to_lru_head) > { > ... > if (add_to_lru_head) > folio_add_lru(folio) > else > folio_add_lru_tail(folio); > } > > __read_swap_cache_async(...) > { > return __read_swap_cache_async_tail(..., true); > } > > A bit boilerplate? Sure. But this seems safer, and I doubt it's *that* > much more work. > Yes=EF=BC=8C agree. I will try it again. > > > > > > I have the same idea and also find it intrusive. I think the first so= lution > > > is very good and I will try it. If it works, I will send the next ver= sion. > > > > One way to avoid introducing folio_lru_add_tail() and blumping a > > boolean from zswap is to have a per-task context (similar to > > memalloc_nofs_save()), that makes folio_add_lru() automatically add > > folios to the tail of the LRU. I am not sure if this is an acceptable > > approach though in terms of per-task flags and such. > > This seems a bit hacky and obscure, but maybe it could work.