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 80923C47073 for ; Sun, 7 Jan 2024 21:59:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C5C566B0071; Sun, 7 Jan 2024 16:59:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BE43A6B0074; Sun, 7 Jan 2024 16:59:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5DCC6B0075; Sun, 7 Jan 2024 16:59:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8E3F66B0071 for ; Sun, 7 Jan 2024 16:59:57 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 5CD37A015A for ; Sun, 7 Jan 2024 21:59:57 +0000 (UTC) X-FDA: 81653883234.01.29A02A4 Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) by imf23.hostedemail.com (Postfix) with ESMTP id 9788814000C for ; Sun, 7 Jan 2024 21:59:55 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jbil0ytB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf23.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.52 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704664795; 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=QflLNr8qUPLYDQm1nMipG0gtGejOsDcOedvIO2RscbY=; b=pHpMBqVfEACvDcBomj0lEhPcdxKGoZRQSDkRmXdkJlE6pSAY2QebpMvCsjPcAFN1NRI2QP nEwzkF6Q6HMfodvBvdMExfo44EkOa/zqbKv9rrtN/TNlu12jeFFl7kjIDdZ+xgw93E7Uoa sF6q4uBJLjbRnL4oX9NXAGfiaZbuUpk= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jbil0ytB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf23.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.52 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704664795; a=rsa-sha256; cv=none; b=6yhi5iVT7p09MNamXv9gSsHmlV46IlEcswDszBtDoXCujwHke9c+v7lyIJ6J7O5l4FXYHm /vh/9bSaueczItuu9LXRuxC1fFBaB64bOT/SyH6YFo3S+2ZT8vRVisWuQIobwz9lgQYoNG dao6dkcs7yU6mRZselz6i87jkPfgWos= Received: by mail-io1-f52.google.com with SMTP id ca18e2360f4ac-7bc32b04d16so61175939f.0 for ; Sun, 07 Jan 2024 13:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704664795; x=1705269595; 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=QflLNr8qUPLYDQm1nMipG0gtGejOsDcOedvIO2RscbY=; b=jbil0ytBqPLNhhvNTjwbu9MeXB5QRSjmUa+axLENcil1/QQ6pSJEu7U8haEkUuNC6L 8sBDtFcrMFztd8FEpSBr0wGnsUFTZxJbO0yyDg62JTDrsUJazOXOdhYQLnQ+fnj8wUtG 4pUi8fho7h+PvcE3Vp9ai0OViRC0AwMPczyF//esGmhmTXL6gzy9phcZzUsP7UCctLnZ KI4sM62GawP6pKuzjj4pelm8t9qio2nPvATbuI3INpu+flqrECqYwPYa6rX2CKRfZxml kYosMYUIQzDPyiqtlt7SxzQZMYhJv6CjJDdGsdNpKjP/dEgREi/4a4PK/SGvcbTvJ6PU YfgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704664795; x=1705269595; 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=QflLNr8qUPLYDQm1nMipG0gtGejOsDcOedvIO2RscbY=; b=m4lTm2z3iCA72FlCuK6mlGMlXHcBLAEMXkKnMRNeo9rvuoxTJxM19NtP6wyRtb9JQ4 WQ8cj4rxdjr+J9hkEoJlgD25IgbPUWL667k96rut7TxJvzSuqADsEK2qRU+7tp29P7Df 8FTbXPMKsgE/VsRq0M2kU0kj+lZhHTtkwJYFh79IMy0/X8WpJf4y/4cKnKlBeeGHtODM dhi+ZiqSmT+1EiN12Hqow7OAa+ZWCwGDUHdXFJocp7Js/KfQcGtkLROdgqjaHELXx9qT TreGwolRBODmwcWbkJB5wg/83M04mwZwce/7jWzzMRUGhIRH+lOe+QJp1oFnj0d0Ggv6 USmQ== X-Gm-Message-State: AOJu0YzlCO++6F+jE+YzdcrlW8UuIV5oOa6/bGYF39AtUwlP8uM2+xzR /ZRTTkJAeU8aua22dhLiPsRuxqAJUdn+vTO2OE4= X-Google-Smtp-Source: AGHT+IHCrw2oJmFjlizc6AVJhAHYjxiof3mCqk0Ct0Ac61iZaCu1g+JrHfShy8PJPny/44YsrgKQsg3p+87z1QeI4s0= X-Received: by 2002:a6b:e312:0:b0:7bc:1bf9:fd83 with SMTP id u18-20020a6be312000000b007bc1bf9fd83mr3210179ioc.3.1704664794775; Sun, 07 Jan 2024 13:59:54 -0800 (PST) MIME-Version: 1.0 References: <20231024142706.195517-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Nhat Pham Date: Sun, 7 Jan 2024 13:59:43 -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: akpm@linux-foundation.org, hannes@cmpxchg.org, yosryahmed@google.com, 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-Rspamd-Queue-Id: 9788814000C X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: gqddip83gpfr51uhskaepiaamoef9azh X-HE-Tag: 1704664795-550873 X-HE-Meta: U2FsdGVkX1+WwARwvXHU01MF144N76HKXy15F67xhSYM8PnCn5lpoj/FePMJsy86MP+dwBavqf0Ah5DGHFq0UPJEzsRg9IEcFbFEzzgOTeC7aizKEE4M2oY046LID6YLyeQ01S7nSgdMbdzS8TcLl2G9o6KUyIjy7zzi5R6vkrb9iBYykk7AJNfHiYheVHilMcmxoBXZBkdz0XaN77hakpwKvcHEphfsUKFtnA7x7P+5zDvbhP9qj87eYIqjKnMYJZaAVSTI+12d5FBuXOK5xJCDKOA7TqsPFVjmnr4brt97/Q5HNCsxrRqI1DVOcNyvX7s+Qx+iMMKjEivF6894+3HOw7GcOPhuCAIxo+NtDJ+Z5g9/KB5DobOfzwtwu+ZNsMBTM9LEqn+oMaDl+f30VL+Kutv/uo8gNxJ5ACOQWwjNcKLCb0nLq5p6FQ9PKltLy6ZmREKL3iC0Gfmvz7MkbcrW6lEyPmK5P+7qZC2ZPii6nQu1AVraHeOd9WfpMBZyJXTdHC2+CSDHc12kupk2YnaTSDzCvG6FKd3Bwv2LG+Nq1ZfA86yQ+sj2+ONcRB07H5ERHXeEQOBDcwFn5SBPeuIttl0HcRRc2PPpZnQwF7P7pgMc5Wk/Aw3vC2PEHVcjXO4kgqtsaupH13LhwwCNAKMcfFtJneYklDQBFXQlHXMHQmghYH249E2tx6uedq2CQQYXNrXUTRgMWIAQJ7bXEz8BhQRWiQKvHQ0TmGOVA3A5MrQitzA9LKlu5A45lHTUp85aHM1/R8t8wHpoQg39Mz4QbK9pdrCXYJwr/bkGdBEXbyCGJ/a2s5WByY+G+1mimMUAhcc3cOnr3fhatuIE9cSTBx3KlCOIpW4MinOnGFT8QFE3ipa2eLhZEsyoAqfwJLYC0QcWKLLimQphOYEG6o9VP+MxiTBUhys3OaBwv0W4rgRO2uwCJ1UCT5uQsu7sNqPUPKnoLzm/kY+qw71 howu1Ozz oaCcyTdwGQxMPpt+tNgU1GmEXMdSKjKXblv0IP15AYyUrQZeMkmTZmH6UeFIu8PlZyBaytuxZheECtsyhiM8Xiz40e3Yz1vmVEp56e9UjkbY5raSRsvdb8Rshc2ph07YrQkJALKtCFfLONFeT19tFVlCZoN5LOHEf186vvVmfUryQGpqxx/9N73Ujr7QLKWOqWcbbvAFZ/6o7uAu7pByPnjaLuhcC20bQ0mrha/I+fuEbBSRxdoeBjQTOE0YkVbLe4P9kQbAMVKwh9Bci8A9bjm1w0xC74djxntdh7m4trqFQzMlEL7W646gpbofcIrqmReU+Rdc82Pphh4v4jJ0UsbWpdnk6wUmPRXj3zj/jqu+hBABVwvBUOHupvqfWC2G4qIHssrY5CkGMKDRFINbpcZZBnEVkSrwCjLPgbIzIpBg21nkLQVHsOLggeUQvnxErlacrALWJIn/Xvwk054D9fBp5c9aTR2eEgLv8Cy+sgOyxydG3KSTmVZqBXY+BMo0VmZmp+A/xZMy0lq4+mqzNFC0CmA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.011304, 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 Sun, Jan 7, 2024 at 1:29=E2=80=AFPM Nhat Pham wrote: > > On Fri, Jan 5, 2024 at 6:10=E2=80=AFAM Zhongkun He wrote: > > > > > > There is another option here, which is not to move the page to the > > > > tail of the inactive > > > > list after end_writeback and delete the following code in > > > > zswap_writeback_entry(), > > > > which did not work properly. But the pages will not be released fir= st. > > > > > > > > /* move it to the tail of the inactive list after end_writeback */ > > > > SetPageReclaim(page); > > > Ok, so I took a look at the patch that originally introduced this > piece of logic: > > https://github.com/torvalds/linux/commit/b349acc76b7f65400b85abd09a5379dd= d6fa5a97 > > Looks like it's not for the sake of correctness, but only as a > best-effort optimization (reducing page scanning). If it doesn't bring > any benefit (i.e due to the newly allocated page still on the cpu > batch), then we can consider removing it. After all, if you're right > and it's not really doing anything here - why bother. Perhaps we can > replace this with some other mechanism to avoid it being scanned for > reclaim. For instance, we can grab the local lock, look for the folio in the add batch and take the folio off it, then add it to the rotate batch instead? Not sure if this is doable within folio_rotate_reclaimable(), or you'll have to manually perform this yourself (and remove the PG_reclaim flag set here so that folio_end_writeback() doesn't try to handle it). There is still some overhead with this, but at least we don't have to *drain everything* (which looks like what's lru_add_drain() -> lru_add_drain_cpu() is doing). The latter sounds expensive and unnecessary, whereas this is just one element addition and one element removal - and if IIUC the size of the per-cpu add batch is capped at 15, so lookup + removal (if possible) shouldn't be too expensive? Just throwing ideas out there :) > > I would cc Weijie as well, as he is the original author of this.