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 0B669C4707C for ; Fri, 12 Jan 2024 07:09:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 816BB6B0095; Fri, 12 Jan 2024 02:09:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C70C6B0096; Fri, 12 Jan 2024 02:09:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 668166B0098; Fri, 12 Jan 2024 02:09:14 -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 586C76B0095 for ; Fri, 12 Jan 2024 02:09:14 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2E8981A0C06 for ; Fri, 12 Jan 2024 07:09:14 +0000 (UTC) X-FDA: 81669782628.16.6D4E7FD Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf23.hostedemail.com (Postfix) with ESMTP id 8FD7D140005 for ; Fri, 12 Jan 2024 07:09:10 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=B31EKyjE; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf23.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.41 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=1705043352; 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=d2axIAZPMzrhQEXZe+OtGDs+tak3gwoRFY7MWaUZjPE=; b=y6Wza94twCxYmcA70F+zjgmr+o/bWnlv7zoCDYJySLPRRHGr+HU/40EeLM9r8xyxMq32k0 OxGqpsPeKQoQ0rn5APmwVoWmS43K2JGB/TD4amRhSXMsuTcLzKjer9Eff9zErDnxjIYfiu FG2Ftvks7ryKoCzyxvChSMPN3U8arZY= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=B31EKyjE; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf23.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705043352; a=rsa-sha256; cv=none; b=RTJ6yTYnAw5KWJ7tumfvNq1mzLIKmB9b3eBUjryKx1MztZNDPxWGKWMy96Jniv2/4OaEkm znxOGzSCXaI6nhg3kLqWtjrEJnNmDvPhtY4aKHf36jzQniFdfGiMEZ3diimEM3oOVQe8Lj icBg4gYbOzhKfGg6hFkO9La9e/5PJ3I= Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-50ea9e189ebso6834468e87.3 for ; Thu, 11 Jan 2024 23:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1705043348; x=1705648148; 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=d2axIAZPMzrhQEXZe+OtGDs+tak3gwoRFY7MWaUZjPE=; b=B31EKyjEUwJpk8MzOuuxgVOEA9cE7PdJM/UU19iXC/ZA3tHORltRDAXtvKqKD3QGfE cNVfAOBMg58NEXTdGWHLXrmelT9tKzk+F2wzICQOm1Kf7ns5+vEmc7IH9RwL4DHhStVN d9CBvTSZoVs9KXd89O3AQoI8Gs+Fh0CDQNm7pYwkyo6v581U9GezwiPhsnFGsA+tQuSt cVhGA3k/D/J5p65zjqa0Vw9QQ3C3q8FoIDb63lf7WG3SDaBs2JdgrDjBaktinJ5l4PPP 51O6jzKflgftx5JOTkZ1nc5747xlhBYKq6C2nIkG8KElUMQbzUjry9Ij0W7geOZ5nxsK Rb2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705043348; x=1705648148; 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=d2axIAZPMzrhQEXZe+OtGDs+tak3gwoRFY7MWaUZjPE=; b=VjCfY1dfs46QtzEe0sieCb0Q6LohmHPEfELcjJC8yXNyiiS5boWqXfPa/0NvJnwIpd dNZnbexBzGtTZ94OzftTX43Z0vb+fPrkHJlvhI0pL6RoGtsPMQlPfOzn1/Jy7gnHqez2 aDnaUMhpXjdhtxeE7kuXkMMbl9bXGySlJx5PHps24BvaH+MvXqdgcUhrPqmI5/5gewA4 daQdS9Arl3ACMxa2bwK4UeRKmyO3F2UNUfEQ3Oe7V6MEres5LUe+VY8NqZJIhyo3JPuQ wc4mO3/nBlo3rLXJrFV54JuiRyQuoIOWaUQNhrtkvua+2Bx0kytu7CBzzYdamfmSlXrM rsKg== X-Gm-Message-State: AOJu0YxVI2vowR9dXI+kvcLAdR0PSzQe8HQQDlepXuXK8c5VUjP+8Y8X 4cgsF69JAD8FXogx7HdE4uhPyMzFbNhUU0DgvmLXieZsfEFeqQ== X-Google-Smtp-Source: AGHT+IHlIZs0OR6a4sDwKPWdFqFXG+l9K8s9gqZcD9ZAf7IQnYsQgAB4rz2ercoFOLwQCg5T3wkbHblPGlddWKM3zj0= X-Received: by 2002:ac2:4c05:0:b0:50e:27a9:167e with SMTP id t5-20020ac24c05000000b0050e27a9167emr348204lfq.59.1705043348345; Thu, 11 Jan 2024 23:09:08 -0800 (PST) MIME-Version: 1.0 References: <20231024142706.195517-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Zhongkun He Date: Fri, 12 Jan 2024 15:08:54 +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-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8FD7D140005 X-Stat-Signature: wwpc46unh9edn4t6jj8ys787oiybk8pc X-HE-Tag: 1705043350-115017 X-HE-Meta: U2FsdGVkX19VOaeS7NIOje+UKGdLA98TQ8zK8eqkDnJzyV50Kp6Qqv3sODE2lGZUOGtmcxmb8lqt0QTCdxrFLaoU0ci3fDcRpvPhs9fMrC6kRPH8iZ9aftmO/S4ScUlC5Hf4baDpRh5N4zr7bouC8ZwQB7Hs/baVtpfg+0K0cIY2bpfC6Ykie7FiJ4mxeE7G/RxgRRbX4/piUWoBoS0G7dwVPIUhsnEqAO6pMa31Pt1bft3OT+uiUefZrgsavpZpnNht/s1Nah+RryWqOx//aDjmyKoapNIvO45Z2NPjiwMXb+YHliRU+IbR9lxeceG1fJb0smuYsuV1wDezUwTXIRcSP2CH+jUQHuvgQePGPFNjGNPiFPXQGNoku3NIA6VfnGRc1JdNm7FPJbfug/sC1a9EtSmSs3bhM7ytDL6LvMTd68kxY8Vy0A6BRliKfQwMUIA+un/rbaf14mob7SoDgYWpjiFzqEclzUeftNNGXkLojfDCQQ+1+Wdip2FS+l8bJOl+yXDxKfT1/E1XK0Hw1jpPa8l1RAffjUMISNOESzL0i6D04W6k82lerQfCeH+SC+tNrU12Zhmgx+zlDhexW4SDZ2lylID0rOWZeugGQjofJbzr77iQz1Kv9VB0qNOWLSY95DzipFsouu4Ndcd5uvdrT5xX1B0w5MY6zNBzcDGmqgAm14FS3+luprWsx8Ufsb6Oyf+RFq0d1Ji1KOgduNGULvBqFZsIR2MGDknhKUkDJGxRu4dGOLJNhBy0WUGjXkf6KBMyKp1x2cjHhoTtnfjhpo3Ha5VJeioN+BG9b9sRyDViLbKkqS0MMCvGg2OjXrUmvqq8mWgNJljSeuv33skG1l7vzm2E+PRiVzMe4YE1pzSbXx3Yrp19BjP7D6rIRFfFqcL1u6m1Z7bDCu9CEQOyZybBtUPH8OGT2oFpegYX35wrCMwpEa5trkZOEjLTIT/qox5lgphpprZDem9 fvw/cR7y G9elStBZiE4uUs1APqRvAQW9lRW+H68/lXEaYnc12MTwcKkLnbEPWCNUHpHwFZhRl0gFgAKUaOT5FZB9uPa4YjaHNV9JsetJDzDw5ABWf8cGd7kJYxKjDB5bNGpwjvJ+f9huMYWmGUnrWc2ymOBcNwmL0Csp3m44itvLZSmN+VJ4KmTl2h+61XhVeOl82Wn4y2TooPjHxNyt/4CPYGh5ST003pl1dDyK14jV3asQf+c6hXeoPGg2K6yrLYC0vYPnpvE/wG1RndIJXkY6L8EY8JeOQTQjTW3g6q+34qwYAAevxTmKQMuwG4o61Xvppz2c0f+2HFP/wzRLdeLhweVk4jmtFikZsfMlh7zr2lp0c5n5fNEUTqBMoV2fyw+rpEc24fbNuj7t3t8tlmSLlo68Z3zuXJf/8uVevVdk6yTgxaC4YyiziWa0QswgCnw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000049, 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 Fri, Jan 12, 2024 at 3:25=E2=80=AFAM Nhat Pham wrote= : > > 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 th= e > > > 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 recla= im 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). > OK. > > > > > > > > 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 minima= l > > > codewise, no? Just a bunch of plumbing. We can also keep the other > > > call sites intact if we just rename the old versions - something alon= g > > > 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 th= is. Thanks for your time.