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 11061C47077 for ; Thu, 11 Jan 2024 19:25:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 984976B0096; Thu, 11 Jan 2024 14:25:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 90D2B6B00AE; Thu, 11 Jan 2024 14:25:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 787AC6B00AF; Thu, 11 Jan 2024 14:25:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5FB4C6B00AE for ; Thu, 11 Jan 2024 14:25:32 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2CABB140522 for ; Thu, 11 Jan 2024 19:25:32 +0000 (UTC) X-FDA: 81668009304.11.DC0EFF5 Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by imf20.hostedemail.com (Postfix) with ESMTP id 6523D1C001A for ; Thu, 11 Jan 2024 19:25:30 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XhxhhQFA; spf=pass (imf20.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.46 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705001130; 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=vg6FnkVOdWEv0+8ytRIEDXW7BwqBOcvuaxdwffWiGI0=; b=SqNCJSAJuqRlg0VzZHPOouRxWssyPGkkqYrZRLObdkq2DpSHlXrhe19KQjBeWBA171eRqx K24IID4y5CTVKQWU6Gf5DwTU9YPQgejDp+4GMs/jcRil8JZ9L5YUSte6drf+sy7h8PSk/Y 2QLDKaq3N95xLfK5gvQ39wpimMBv/8M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705001130; a=rsa-sha256; cv=none; b=ZpcTpqXHXg76iB8QmjRcOk4eVNOo2LmtIVg2kSCRysBqAkUIQ+zXHcoEcS1LDPZumZk2jO O3/Cv3shE7bxT8lYeQ04rcbIZGDTr1G3YzDHitg6jifty1zb3FdGoIcZjX6fSQuZ0enlGi kCRfCS7cMoBMdP9qSWVk5Ynmos6ZIIo= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XhxhhQFA; spf=pass (imf20.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.46 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-io1-f46.google.com with SMTP id ca18e2360f4ac-7bed9f0ea20so111652239f.2 for ; Thu, 11 Jan 2024 11:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705001129; x=1705605929; 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=vg6FnkVOdWEv0+8ytRIEDXW7BwqBOcvuaxdwffWiGI0=; b=XhxhhQFA151oCpeq+bt4Ka5Lxm4P45LaZaFLsidR8fFUg+7CzgfpiBd0adSTPTic0k uXKbKa16sviCBBayhTwSslRI6gNo5BW+oNURMHVXuG61eP/n4HzUV9+mgXoqtBJ56XLt hiln8MsjtDmnv8rmh068CBWI+Ppq6ZWCfSCbyZ1DciJVAlrIrcIWwPCSw/hCqLJ7x5lt pf4pi48Iyy42Pkvq2zjSMpxrYOrs2ksP7SHNh0YrVRgvdWzjQl5N7ieKdAI4yhrjw5Um 3bJxBiEiuRnO8UxOSZsY7JvqWap40EfZTk1mengIzlmKWXcDlFZQ1SRwdr+yMk3/Bt66 0a4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705001129; x=1705605929; 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=vg6FnkVOdWEv0+8ytRIEDXW7BwqBOcvuaxdwffWiGI0=; b=BC7HfiOwPxDpSZ364mgWA4Sd2XuKAA4nK3MQHFHITgBSCHCBDaHwj4GmQjyXKNcusN 2i73Tat0xaO7RnF8EQIWbXriRzWcsYrcWOHW06FSJMe/IR/XAAxEYouK8c60zF1Kooi1 X0xidZd7CuYykrfmLkvMMAVIpANUWJnNwMtRn3jKlxO5HmySU98EgerSLGvELclnAznt 706/Y8suSLuul6EdzGbo7ZpmNJd0JiFzUUqEUIQvJfyz7hH48Wxti1+xB3fV8+aKZBq7 gKQrez2DQniEysfxS15R+aqOE3CDp2ZRcFqPIyWaG3xzGYVkBBP9WwXCVKWHslzfxETa QeNg== X-Gm-Message-State: AOJu0YyasOdHG+E7F0E8jWNAZZIrnPBkN4SAyXj++1L0K1DkazANW+bf rHFqFPyRe0Z1bxUlrXXIMhbxH23h8Wrw7OyNoas= X-Google-Smtp-Source: AGHT+IHE+qXVynwxYNyO5DvdOo23alqFfocIn59zqDm7cPaShqSZHiYuVVyN6gJUAu6G5pb6cEnkqXug0iax5iy0E1A= X-Received: by 2002:a6b:f107:0:b0:7ba:b744:bb0 with SMTP id e7-20020a6bf107000000b007bab7440bb0mr160243iog.35.1705001129464; Thu, 11 Jan 2024 11:25:29 -0800 (PST) MIME-Version: 1.0 References: <20231024142706.195517-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Nhat Pham Date: Thu, 11 Jan 2024 11:25:18 -0800 Message-ID: Subject: Re: [External] Re: [PATCH] mm: zswap: fix the lack of page lru flag in zswap_writeback_entry To: Zhongkun He 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-Rspamd-Queue-Id: 6523D1C001A X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 9hxdgxyyw5ibkzr6i3jsgetdzayb18qu X-HE-Tag: 1705001130-80841 X-HE-Meta: U2FsdGVkX19WnIpDi+2Xt0NQYabxE7ocS7V8UdHozbxKLm/yAHiqBxuj4kpqjnu2hYHhSuMRDYdSATNbZxJpGKAD6No1nAkaKeJioxmOyEiSP+neStQcOA+WHHHdrgPmZqBFIicxGttgsDkhGsb/QBN+1ZJQwIHkVqLi0MJIqtSWAoWL500WkFfduCKVr31jV0yck4n9buV2PqXME47rQkbIWmSQI2VERjkIw21tYDCPkWAGkHcQavi57Ny2rQErtN+9gwceLnwuLlLxT/rgzZRhfn2SB624ETM8NCHjy6hErFAD+kUR9rsSpofhJahxyossnKZh6Lkwuw3nj6MWX1349VJ3b7MMHXmrm0C5KE3RIjdvXDyZa49ecEEn2s7uG6cY6BS1n+kJAnlh/88LqaztVZYqjT2Pg3ep6ZED6nzQy6jtSJ23kShbm6MIlzZXwzJ+GbvYF/bt+JCpyUdJai5R0bqcP61rt4j6kBoa+kAzzQjKk+sTCOb31fSTCIQkW/1/4pJRvCKrRNHBgboFQw9QnN4p6St0FwNCimorcrvUorsrStORHmv4Gnb/AguQtIxktQmeBIqR0lT/dqThklTz82dVWeQilZQjqIXnGNyRem9mp0jSd+3/DgO7JZcdPdz5/uMDt5MC6OpsTjfNofQQx4T13FIpI0ew+Uvk/DDdgqWUlmgjwdIfz5ZQqZAXwsGrlMQBc4fmvUysA5JKH99sF8GCmeLGXXjaLzN0VkYlF8IF/ix59sQlShHv9ymJkysxux7vh+MWvN06oJGIvr/ALs6Sm3qeueaV/kQVIhqx9Uw52txmRSwUtWvWoxERfo4bjGyu4PbzIeqvWH9hEuaytodmrcvDw6GTXQ3MSfpDU7znMX2sKT/hh7SKVVEmRhqVs/iIoj0ohddYS1vlrxYXkrVwMZhGGeqUUBO1ctoyxznu/eGfHmpZmSnj8p4N9sjHtqAkflt+NSY0YAw 94HmF39J 9onpjh2NfIrGb5+8tKp2U1xyD7bXTQt+mB2Q4qksqjNp8K0wWKq78Jaddi1LDd+3GCoDBt32wWU8ZcbFdaDxPVqIG6Y/dovpfzU37BrhvA5devr39fx17LNkVV49b/WwXxDoKLd3bFtFjL2+mzyR1G9HfWSUCOtkVE5G5wMNPDHQ4CcHh+n28afPKxEnVH04nXibhERM+HMOMXjrmI7dLXZzIf00mQGtyKKpIV9lSHmPufvUyupNzD3t1EONTSmmBbf4cpsaWUg2Vp7jF4Lp7hH+/nu+l/JyiuZY3SQS6LAV5hEYYMRMAPV01e6AQCx07AUFUqf6D/xsmrMAx6aRe15I2jp+MUitwIF4z/4jixDKFn7M= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001984, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Jan 10, 2024 at 7:49=E2=80=AFPM Zhongkun He wrote: > > > > > 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= =88swap=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= it > 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. Makes sense to me. IIUC, that's the original intention behind calling SetPageReclaim() - unfortunately that doesn't work :) And IIRC, your original attempt shows reduction in swap usage (albeit at the cost of performance regression), which means we're onto something. I believe that the folio_lru_add_tail() approach will work :) Please include a version of the clarification paragraph above in your later version to explain the goal of the optimization, along with suitable benchmark numbers to show the effect (such as minimal change in performance, and reduction in some metrics). Maybe include the link to the original patch that introduces SetPageReclaim() too, to show the motivation behind all of this :) It'd be nice to have all the contexts readily available, in case we need to revisit this in the future (as was the case with the SetPageReclaim() here). > > > > > 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. Look forward to seeing it! Thanks for your patience and for working on this= .