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 9BD78C3DA6E for ; Tue, 9 Jan 2024 02:43:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E26A6B0071; Mon, 8 Jan 2024 21:43:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 993586B0074; Mon, 8 Jan 2024 21:43:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85A6F6B0075; Mon, 8 Jan 2024 21:43:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 72F056B0071 for ; Mon, 8 Jan 2024 21:43:30 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 34F26802BB for ; Tue, 9 Jan 2024 02:43:30 +0000 (UTC) X-FDA: 81658226580.24.50124EB Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf08.hostedemail.com (Postfix) with ESMTP id 47E5116000E for ; Tue, 9 Jan 2024 02:43:27 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=LSz2uaWq; spf=pass (imf08.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704768208; 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=BwBZsH8BcPmrXBFsDiVkOfnprXScu6S5zpCjH/rm0pM=; b=hRIAg3H05Wza/CHouU3Ss1CUbhUmaQsCGW4dnCs9REj2vDWYH1+32WfZq6fpY7KjxZ0ccV RB3uYjCZDDTfY82kKQCtdXoNwDR5MFlGWjQNqWfv2sCajF+m74V4RSb5Nu0DCSUrMN5a5v K9HgX9FAt0OeAeJ3GqzS1HJOfMb+lDg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704768208; a=rsa-sha256; cv=none; b=ZyElIYKqD1ItdkZf6xIrJcQ44UmCR8UldqhDkTntKn3+a1rrwmsPo6PzTT1085RcdKS1VE Gj4Di3D9WP50/F8AIUrjogkoe+1z6xy9kAt484pUlnriV3wc7s7c9VsTfFwSMj05X371GS yvhYE02bUA+tgeNXoTCG7MZq9RJ12vY= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=LSz2uaWq; spf=pass (imf08.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-50ea98440a7so2318236e87.1 for ; Mon, 08 Jan 2024 18:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1704768205; x=1705373005; 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=BwBZsH8BcPmrXBFsDiVkOfnprXScu6S5zpCjH/rm0pM=; b=LSz2uaWqZmEsSTnkUtRBRDxiZkedO42G6Lh4Z/NYSYNY86mjd4DDoHNK+o20fBmJ4F ATBe84RyupNM47FslXtrCFoSE6M+AGHOFyKqEHF2I24+xegpyqz30SdKX7ICMIjmzK69 piNRXNW/sT8yS8+GL1j/SSEc/symslt0oEmHMArkXUzblK9fCV6gqetbnnZCmc2O61FO MTsh5P4EGQEOktYii8BllNuZZ/8sx/HZfTpSvoRBkpjyaFYKCD2eYVGrn2Ho/qb2iOGX vBDmDG1XeFJntIDdoyqAuY2HDbLDBwi7AbrcjGyMpe/QswxxnjBZZDQI6n2zT71y+KJR QIEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704768205; x=1705373005; 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=BwBZsH8BcPmrXBFsDiVkOfnprXScu6S5zpCjH/rm0pM=; b=RfT3ycwGQ+9LIZata67teiYbKM7sUp62yu2NafHUYwKaK43rvzo1O9daQ2BzNCjvgd QXBc1NKlbuk+4xwd9VC5DxHldcGKbKYSPoS2OE8LnmeQS4c6LNe7npdwpvaPCyNxYlfV dAUnYfu3d6qYKIy+4XT19Kzfx+MWCkylILtPN/s7UjhXp5+O6UHJ/9XgURuMnsC/Sncu pheYB39NpbweO/DJ7ZIFhcrlmB/YGFLUM/1q1ZLzG3FxwmeN40C2xdKdD4Wc0NGx1GbF JJhk4xfqHdorDt5bDE1n7BNj52Vqa5DRNHV+1+B5bZG4VsVb8TDowJgq7pbqX5tCy+4p hB3w== X-Gm-Message-State: AOJu0Yww9XV9i3RrdqFd0MNmh088295MVGvTaZYR12HrIbN+OaJYWd09 lX9VCRGmI8L9FRRaq5Muq/vDbsd5k/abMhcqgl79TrF3vDEduA== X-Google-Smtp-Source: AGHT+IG4fOGnqM8Qe4o+balfTJDtscCuFqdajZ1EGzXvWvcho5ajCu5tNvih36fOvsTH/Hd48o8m3d1CvBA84Hy+Re8= X-Received: by 2002:a05:6512:1086:b0:50e:811c:65b9 with SMTP id j6-20020a056512108600b0050e811c65b9mr1848810lfg.118.1704768205232; Mon, 08 Jan 2024 18:43:25 -0800 (PST) MIME-Version: 1.0 References: <20231024142706.195517-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Zhongkun He Date: Tue, 9 Jan 2024 10:43:14 +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: 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-Stat-Signature: wj9i68pf4y7a6nh6hwhmmduingqai5cw X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 47E5116000E X-Rspam-User: X-HE-Tag: 1704768207-460883 X-HE-Meta: U2FsdGVkX1+9A8gVIJCNbnNyYPkfoYulJo67OKWJqibIql4BMjKMNMv4dEZUMIM51MpYuYFnt00LuiYH2+BLDXIal3s4cs6qo0x+GtXP826c3nO5fcUvFiSujNiNSQcYT+McgWhseXjfJR0chw7LdChJouKWL+XtaU6FfMxzJmzkTLFt7OyDaEB10QgU8cm1H4Zkjfh9siytUF0wmmK1TkSlWafXNwr4DOulvT5rfGKr4ZHKQWTsxFd0DsU53qcmGJXYjWtSq5h8bfukewAL3PAn40bcDHAEaEIlBHOdzlEZ/J1gm8d0uHQ6w80MoedOYSN9nuhHFtG1p8s7OUofyOsoWTLobpG2lXVE2rEmI0ReyKZ0y8T60waemixoJTQ+yikz0HNSzjF9HDjBg7rGhovprjRKvbXxWBANS+myJZ+J7udBiivZAfPQjRiVowML89tjrEFCxiIjG/ZB9xfSiYDldHs5+kN+SMFg/In3qHM6WD5AMpZRyjjhsGFWyYSJX21KGfDAKr35prwm442Loa+JWj7f//D2BTWDbpzHsqM6GkgRTMuxHU2EfSiGP0vK+xSDpodkOgVWmhlRSBPMKK+dYSn/b5tfiCSE3S43f6H1cUN6j3ZEVdh7y6YXwB1FjpVqjjoB2wLWdlDJgS86EXbj1613WVjxye2hTQDoJwcSUgreUCd7DPRKO8Mn4KOLbcRVO4iX1tItnKrBHzVC6OCOmWKeQ8iRTxZ7xC7RYX/klDVRg0qY+JehDaPK3ul5lX6B8XUgG+YhRkOKSl46LnXpZdJQCPBnUziFFlBEVpAFM2lOvQqafdImAMgtH5ATUKVaO5iuL3I8npfcvNQDR9Vd20uVQaY+T4Y+TF81YbyVhRMNER4GigezVlvldw6KmSqQTgmyvlEFz/pqz9f6IwLaA1uW7FHwHaUuhPrr+hBy/MpxpyWzMlqCJKnJQ+OwmNGbpwdUnNZC0xwHpui YQEZ6sta 4NgVeDYW2P0YsJOqKpOHhFEzJsS+MwT+aRzPcOzGKqWIuiKImSO21VO9/BitiIqDwp0I/akWYFS0uYtcHfxpaICp+xv5TBfvXA4iZ17ruF1uy5sAhKRjlYrPRa0f9sbVi9qA0PwJsM3+r24rbRhTLbYwOdLMgZQjRYTmRJZD4j6ZIjcFP84ESu4ugTmr5rrfEZJjX4Gs/b6jbVB3NdV8pwT0nrHSx8FPwgQus44gSeW5ZRRWuHU1lKR2g2bEyjSnTwzdZ/jQHfaDibvgMg/tszkmpkq5rf7wvepQh4+1OzC9uuXndTmp8DLdjJ1o0VFlktOv6Xwys/8Rc6X2HQ1nPKHNW+bQCrJnjdmRZ05j+qlIJ2YhpqWVOPbr3+Gjhk2r/m2h1rjMw000KEyIhJkY3fkoa7SyOi8je+R2Acpc/omLOdi8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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 Mon, Jan 8, 2024 at 6:00=E2=80=AFAM Nhat Pham wrote: > > On Sun, Jan 7, 2024 at 1:29=E2=80=AFPM Nhat Pham wrot= e: > > > > 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 th= e > > > > > 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 f= irst. > > > > > > > > > > /* 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/b349acc76b7f65400b85abd09a5379= ddd6fa5a97 > > > > 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 :) Thanks for your time=EF=BC=8CNhat. I will try other ways to solve this problem. > > > > > I would cc Weijie as well, as he is the original author of this.