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 90240C47077 for ; Thu, 11 Jan 2024 11:28:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 05CB66B0078; Thu, 11 Jan 2024 06:28:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 00C6B6B007B; Thu, 11 Jan 2024 06:28:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DEF0A6B0087; Thu, 11 Jan 2024 06:28:25 -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 CAD7B6B0078 for ; Thu, 11 Jan 2024 06:28:25 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 91ECF4045E for ; Thu, 11 Jan 2024 11:28:25 +0000 (UTC) X-FDA: 81666806970.04.10D0568 Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by imf20.hostedemail.com (Postfix) with ESMTP id C2F601C0007 for ; Thu, 11 Jan 2024 11:28:23 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=A1c7v8bg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.54 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704972503; 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=1r4p8EZizALAha2W0BpFV/ugv3SVBdRsaxVwbhdyofU=; b=kMtgqAau2IbYPzKrhzPC3IWawdRTxKCel8jCbvtnhnLgDBayIE/DnRvlJfYKjFXeAS+25I 1ErMlGXW9HIywGcqjL0SozfxbUZfwuvC9POpoS66Ih0T83NHFyGuGov9SPS6Iy45KljdYm mb8qujvQNIAI/qKOaDt05HRx/mib0sc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=A1c7v8bg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.54 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704972503; a=rsa-sha256; cv=none; b=psJd1tEtP4n9s8CuUT38xpp2/ylunksQdCjPfJcyeD4ZADBu1e2LU4vUODlb9X/6HWBj+9 X+ivAUTl1x4yhujba1vbLuyEc4FwsvM+ocymLxXKROs4EBnaxiACcwWnTVNCcfZVLOO52O dqsWSq0NC0tS5ga+Yp0c2zX8rzpc+Dc= Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-a2a225e9449so561073466b.0 for ; Thu, 11 Jan 2024 03:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1704972502; x=1705577302; 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=1r4p8EZizALAha2W0BpFV/ugv3SVBdRsaxVwbhdyofU=; b=A1c7v8bgbLr76FCo10pXf2JMJnDgAn4H8De0jIbMkS2LcnoaOQi4d6M/mlo+OjiAy8 +i2v/StOvKBoGXzog4jJ9/mCV4Rq+0SMzofhGJPMNiY6LAhnxH7Yx3aT1X4KGHdeBibO pNQD6TCRB360OGa9lRQ068ebkNJLb0xWSqd9w231V2OSL5uqhTpOxAq+x14YTxmSm3wJ kbwHe9ygv8XeigYhPKfOV2mUacj/qIljaaMrR9H406RtjG/icDD8KDsndV4MwhIg5qfX LeR3Zp54ugsRv+QYGBcMzfnrYidmL7Oz+Sv5+/KGNK3c3oD4VAc26ZEC+WQdGlbDCzlF STRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704972502; x=1705577302; 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=1r4p8EZizALAha2W0BpFV/ugv3SVBdRsaxVwbhdyofU=; b=TPdKgdwhs5ZGL+PaFgWmhn684yg2qqGG4TtAKFddjXubYF/njxu+6d5vF2vyJXHnek qiuzx7cVKWo+GMKrGxligrxS7l/4DqmCYGkv0NY7HgCGz67C/7iBc7NryBH9cBhqjqPY ki5If6OF/XiSoP9Wpe9oOOsRIYbJPsYtltuxEbPBuWP4hcUev+VOM9hH61FS0d2flgOm tPRBXEkVigkYxNk5CyAxT0BjLvUVcE4RZoHs2V7t8iXBsFs7s+C0VyLx8gnLRhPFx70L OdQ32z1K8cpx1VgSNC7LFWpxpCqoQb26r5OpVo6xrmoE1fLT+wL54x56/6wTLpWfo9j5 d65g== X-Gm-Message-State: AOJu0YzPEYqkJGnqeLlw2xsWd1c17+ZsNy6n52WXQHkkWlMO5pJyzPam FI58JTTugwrBP0BulLkU3R4JBbmKPk72rg/isccFJzdaDZPH X-Google-Smtp-Source: AGHT+IEufoHkvLSX8vgq4YGEOXKsTE0opFs0mnugITz8vjU8xo4oJO5CX6Yg+X0XoMd4DWqJkwdFdlvpvUFOV4j5AXg= X-Received: by 2002:a17:906:2496:b0:a2c:4a17:1d66 with SMTP id e22-20020a170906249600b00a2c4a171d66mr425894ejb.47.1704972501963; Thu, 11 Jan 2024 03:28:21 -0800 (PST) MIME-Version: 1.0 References: <20231024142706.195517-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 11 Jan 2024 03:27:44 -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: Nhat Pham , 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 , Matthew Wilcox Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C2F601C0007 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 4yetfrqp5i1wneys9hhox9but1j17ge3 X-HE-Tag: 1704972503-854057 X-HE-Meta: U2FsdGVkX18EQDfV3oGuDxJfMIODtG9T1Lb5P1M6fyWFSkkL/9ilBNn7zDqyE1wEfRfheFWQyadcVtexs8c0GK1n/7dkaEVZBZDDzdXa0Z/Y3MJ9jayo3zU59P5L/8z5GN7zxNH+FungmLyPRkzzwh2kHoKlEI/RCE9udlreYz9upa8tIl8zNd+P8lb4/8Avxu34FI/2A2wajI3wqh8f590b9l0IUfIzc+7YuV4yZloA/aa+rBsvJbHkYGgNuEAwitC/XUdI98SZV9v2Vj37uThTb351NzAzu/sis6p32XXV4U6Y4uWfVg2GntMJn5dGS5BBgUv5xZvQZwNwkbbA6KwXwEhISYxyjhXSvhNNj9NqXBmKCv8/t3dbX1X1Iy/sqlUss+oYp77y81V9b6E/KPyHCB1EDmEu7oB/935Ziba5nNs/79xOIY1ir2yUEYqjeFQ585pPuavBO2omR5HBmtb42uuMX79KTgCUeN0rjqNy7HiUatKtJWF4PV+3Kt720qmA5sN5I6MauFa4BYfwtcxXZCCGruxA+TqegHN/qceCOftSWaLQ59MxzvlAB6XDCL8eVStiOExaDf3ANX5u/aWN6L33Qr6Hv5Mpbl7cm+MIhs8a1GmaYcKSwkyelWmwrRnWRf3fMnj8TcpDMPl6xghLc2BH1ozDF6KwdbRGdowwS3CLVLQUv9ae5duD/pAJw6pFa2kYOCqH5M9TfXbxOxO4pIZwRC64xteX/Lu6OdwZSQOXO9XT+/xt+GGtQm6PuTSaSCdKzPqT7uqPpi9S91iY3jBzOXPULffWRNPb0/nVCQJotdug+jFfRHZ1tgkEChWmDj2f+ezK9+uJ3/9hnRD/GkMw0GChELm8Om1rc3L8Vb/LObHouecxFvBYHKEfV/u73uXwznOhh0HtamIhLmhjixWyPr50dPnP9K44U2oCDoVaIKDRVE4e0DzNNtdvupszZLrN1sIZJADZfT7 Iv//2UQO oCS1YATpm+sZVgSCrxRzSybH8zmmfpov3gVWpwC6yqR8deARFCsjqjjHALU+HNZHJXs2Y0412cRp6ByCp2lFnQd56qPLJgTzfm70jn4WAASPc6QU1rHD4N3xsvSmV5POnSwtb+s5ipj5YJ63TiWxxZlgyfp5cN/hMvfKt0PNHahx0KYWe6nxF8NsFjuvq62smpnmrH4fOpvI9QJbDC5L3ZCNuLI09BMN4B6RWd/TYqYvxT8XH4Tx2xErLCfiuEgH81tHXN6t21ZIid3b+3hlpEw2G1RS1GcBSZZdiJxKgKBiV/MOG4xzghgy+HtFrPwIc/DAYppt/qz8eTPqeYUh/IMh/QGOWQpYhfH6RRh3hLzradA0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, 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. > > > > > 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 agree with Nhat here. Unless someone with enough readahead/page flags knowledge says putting PG_readahead pages at the tail of the LRU is okay (doubtful), I think we should opt for introducing a folio_add_lru_tail() as I initially suggested.