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 C4393C4707B for ; Thu, 11 Jan 2024 02:57:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E7A96B007E; Wed, 10 Jan 2024 21:57:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 396CA6B0085; Wed, 10 Jan 2024 21:57:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 237866B0087; Wed, 10 Jan 2024 21:57:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 125146B007E for ; Wed, 10 Jan 2024 21:57:18 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D27CB1A053E for ; Thu, 11 Jan 2024 02:57:17 +0000 (UTC) X-FDA: 81665518914.10.30FADDE Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf19.hostedemail.com (Postfix) with ESMTP id 2D6821A000E for ; Thu, 11 Jan 2024 02:57:14 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=j7WClNuc; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf19.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.42 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=1704941836; 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=OC4cmgp9pWBEGhOBagPxmTGQibwekEdPdcD5cLk/TkM=; b=VYnDRAb1s+86SwXrrFEW9XSx7M/NnWUXAcwiv0k6agcN8W7I5e5uVef5KLpjH4NTqn5qm/ PnVu1UWT0dix4PCbqcr0RuPIBnu8F2st9C66wGuE/pvnZSg8dOR61I1Drmakj30aLvWt3m MwBkjT3VTBfaVygafk0rJwW2Dz25v5M= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=j7WClNuc; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf19.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704941836; a=rsa-sha256; cv=none; b=R8RHmvNYlY7REzbly3TMzmM6AN9PbANy9ONu2xdWBpBgaYd3h9Uy6Wf33AJ2HPRpf/iVY4 LNIKK6udbo8PDxdxAy76eIGhnZ3tpmzeJ+E/1MHHGWKY8lzsbp/9gaUGoBUHlS+Jm2aiCR TkqqIC2pc2FCy8JaohXdFTU5hT/9T8k= Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-50e7af5f618so5434488e87.1 for ; Wed, 10 Jan 2024 18:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1704941833; x=1705546633; 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=OC4cmgp9pWBEGhOBagPxmTGQibwekEdPdcD5cLk/TkM=; b=j7WClNucjsmxXukS/T7GXMXv1MtX9aRd0IR/+sNlfM6mRShrmu/yseUiAQ0OpdoQFM aTvFAXl7b5t7M+3QY5QLLNv9ptA0yQkmeVCMBgjywzhnEwYhW7MPsR9M+i6XhuPMoqfc J8No+S8N7kau4LQ3ucfwH7JWRB15ktWToIuBYri9uIhs350pVrmgoadB/qJMwTNA1SRm qU/9al6h0TAH+NSDl1KnkP9kAGTwa8/vczMICXlSUzuWP2q0l5fzbGO3g5ju64SvBOcT soJIhFcbQRLYx1mmpLQ3zjQozPSAqk8naUGQBKNYiDj9nh580RkKJZcTp0sI6nY/nOoY UtRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704941833; x=1705546633; 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=OC4cmgp9pWBEGhOBagPxmTGQibwekEdPdcD5cLk/TkM=; b=CBfcnuvJyj5/DtiheVTr0XyMJbVbHoAee0AMumdjf97UKM/HscFGqOQ8y0Jy4ddB5l 86fRXHvedm6ZF78YIETRr9ejGygbGALSoBjnx+T4r28YJGBPP6Ig02bH8rrlprIH1nyj CW2qd1Se6xORT2hXlAXAjRP73xf8HGWjeQdPAZig9si8tqwWDIB+eS2fk2IZcLJ1nAMA WpYQGfk9X3nrrZG0ujjy87pAe2GaavBnMuAbQpsA8dC6j8Z26k3LY4bqsMYkQyishPiX AmR/REoRU3OJrMCaPUaQ1ee/thnu6+nFfXXkgSgAH+DQJvbiZqm0NXxImm57W8XczPkI bYSw== X-Gm-Message-State: AOJu0YypRSyKtDmtp+KS3yGTL/CGJUopVbysW2c9i9xrFnxuDdapqTfV juJHat10g72dxu2tufTE2GWMEJ4O3+jYDACdAyGw1NaI8IxXPA== X-Google-Smtp-Source: AGHT+IFi/KHpOgJuGKk7ESds2OVHQsNIjmazI+pALjU16OyAHTb4jPaflRl0/gga27RS1Yj5AeEH4Gym9r/kLZu5u4Y= X-Received: by 2002:a19:ad4b:0:b0:50e:dc99:b9d4 with SMTP id s11-20020a19ad4b000000b0050edc99b9d4mr148314lfd.44.1704941833114; Wed, 10 Jan 2024 18:57:13 -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 10:57:00 +0800 Message-ID: Subject: Re: [External] Re: [PATCH] mm: zswap: fix the lack of page lru flag in zswap_writeback_entry To: Yosry Ahmed 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 , weijie.yang@samsung.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 2D6821A000E X-Stat-Signature: nd3q184i63xop4yu7b48nedieh1wd4y7 X-HE-Tag: 1704941834-847635 X-HE-Meta: U2FsdGVkX189NpcHgecyHp7EfHHyG49fZi96CYcLWD0Y0fcoy08go4Sd8upKlA8Cil4WxQ83xnCOdLWoQ0YAwOZsr3khEteAtkzqrQ3sSFiBbrjZwnReyPgO+wP124/U57FFKSsMY6TUwnuR/JOnYftRC4KfW6P+WHC2lD7/+Cw6BYzXw7Q+V05gX5qwONj1uhx+aeabFKgYs4RRp1t3tlabW1h6bYr3YTDrRYgjsFKf6wfCUJ3tNY1xI6lBHnwbR8hSJe/k5Y4GUQjwRtntriOFxJYNIf3E1nki/dLAOi1bVZWAQetflwOcS2WlAWFcq/ap3yImifiKNkCPDFBGgZsv/G652Vr7AQmO8RtIta+OeY+Hw6ksjdS7do7+tFjuWNGByCBEL/JVE0PAwwWy6pITMpDgGh5I7yDyF0VaNHgqpmzn3636RWmt8sRjgM1fUhSx4v/CQBi6ll+mjU3DTaOBoHYb0sY+9/1FX8Fa31icYcK8aPTwgiI0ZCiUBJADHhl6d4c10FHp55V3iB+Hl4Gnho8l2M2cXplHpTMGIdVymBc+zWZePFOobbqpic5MYO+o5joYR+kgfkSgYLXbE3+w0deaJVrC14d+Smqc0D/OyZcVxGUstB6KfDZ4DI7z/RAfxX0dx7j64ehu5fp+TkprarahuoQcp4d0YAsYUeS4aKmtr9LsD82fDV6HAUwPUvtvOPbKfSN0DRjD1MpUSLvKgFzXksvwk8FnYWyBJAVDynvK1S+xag+vqSD/vgDyMxubMPpaie+wXdDHnJPS2VHaAeAvCX/6+HraH77rO2M59wYF1caaTyOAxEUFxGZuPFI/YDZLKjXCS5z3fUXH6Kga/WglEuTMdXRK3YmZa2WYGleh5q8Dl20etjLS60ePBfzr5dL1XYUOhdPrrmEqCO0c2jlONpD2hdo6Mbw/QsspzmAkXKk5yPjnKoAYwh7edyhQziRUNuhl9SP6sO0 tg+PBVnZ fBClRTCczAf7Xvzs+AG0GOCHUpHWLzIOwHdCKYM5HFAQZfMWnHvTUVBVx8bv96/sDBJnOYrclbo1EMec3RGkXZWE3btcJq9DOVCLvkfLAAU+EhsCSL8GIjTAHV44H32nOYCu0dWQ8buu8kBMAoqwuoyjFQogu9VGeh03tCnAZc9m+IpcpiIGePlIsMWkVpVDtoxqAe2+RMqDFMSn45zJTqycVyzhcxR7JUqE2nGldEr1GW7qwDlbKCRbMCa2+OIptKwNtAKWv5JRRgL8EHO3h5+h0NB0Tt4hj0FeihEIJmhl1mWj3HPYKC6qsKoFcZ4vGEeVN5ygvoTFQQT5KpROjasWrFrYecG1kUFVl4+BexvYxp0h932dPfezdVFbG82JyAdQ+h1xr3ihxoq68GpCvfutlmg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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 12:30=E2=80=AFAM Yosry Ahmed wrote: > > On Mon, Jan 8, 2024 at 7:13=E2=80=AFPM Zhongkun He wrote: > > > > Hi Yosry, glad to hear from you and happy new year! > > > > > Sorry for being late to the party. It seems to me that all of this > > > hassle can be avoided if lru_add_fn() did the right thing in this cas= e > > > and added the folio to the tail of the lru directly. I am no expert i= n > > > how the page flags work here, but it seems like we can do something > > > like this in lru_add_fn(): > > > > > > if (folio_test_reclaim(folio)) > > > lruvec_add_folio_tail(lruvec, folio); > > > else > > > lruvec_add_folio(lruvec, folio); > > > > > > I think the main problem with this is that PG_reclaim is an alias to > > > PG_readahead, so readahead pages will also go to the tail of the lru, > > > which is probably not good. > > > > Agree with you=EF=BC=8C I will try it. > > +Matthew Wilcox > > I think we need to figure out if it's okay to do this first, because > it will affect pages with PG_readahead as well. Yes, I've tested it and there is one more thing that needs to be modified. + if (folio_test_reclaim(folio)) + lruvec_add_folio_tail(lruvec, folio); + else + lruvec_add_folio(lruvec, folio); @@ -1583,10 +1583,8 @@ void folio_end_writeback(struct folio *folio) * a gain to justify taking an atomic operation penalty at the * end of every folio writeback. */ - if (folio_test_reclaim(folio)) { + if (folio_test_reclaim(folio) && folio_rotate_reclaimable(folio)) folio_clear_reclaim(folio); - folio_rotate_reclaimable(folio); - } -void folio_rotate_reclaimable(struct folio *folio) +bool folio_rotate_reclaimable(struct folio *folio) { if (success=EF=BC=89 + return true; } + return false; } > > > > > > > > > A more intrusive alternative is to introduce a folio_lru_add_tail() > > > variant that always adds pages to the tail, and optionally call that > > > from __read_swap_cache_async() instead of folio_lru_add() based on a > > > new boolean argument. The zswap code can set that boolean argument > > > during writeback to make sure newly allocated folios are always added > > > to the tail of the lru. > > > > I have the same idea and also find it intrusive. I think the first solu= tion > > is very good and I will try it. If it works, I will send the next versi= on. > > 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. I got it.