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 74110C47258 for ; Wed, 17 Jan 2024 09:53:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 060E86B007B; Wed, 17 Jan 2024 04:53:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 011116B00AB; Wed, 17 Jan 2024 04:53:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E1AA56B00BE; Wed, 17 Jan 2024 04:53:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D0BBD6B007B for ; Wed, 17 Jan 2024 04:53:03 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A67941C1561 for ; Wed, 17 Jan 2024 09:53:03 +0000 (UTC) X-FDA: 81688339446.08.DA050FF Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf27.hostedemail.com (Postfix) with ESMTP id 056C740006 for ; Wed, 17 Jan 2024 09:53:00 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=XEyDbiAk; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf27.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705485181; a=rsa-sha256; cv=none; b=02Gl+jzkFIXbQ8c2P1AXsskE8Hjkbz6TyOQ8RY7318z2s+4jbwmaTjfMVmVuFF4ON8A9+9 e0YvW7+z38ivEUKT8D46XPxHrVDWi6/ZvtVtTfOAmcuIqk+xKvHwvkKpaZVz8soV4i9W9K 4+gR2/x49YTuhGozhPx7GsJMRAqxhn8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=XEyDbiAk; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf27.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.47 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=1705485181; 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=/N7eo+PKWQbtdhFE2Ma1k5gF85XRa6NcuJZbycWLyxQ=; b=wBn9IrpYDgdGyIv1Gz9CU+8Xi9E+9UbasELYgEj+bW/VMAAre0VG5P0QN0FigPFI0M3/xX vJoCDdCOJVRYOjK6tVEbF/yELQg6RJEhglw1UMsvWvtnYIeuq17nEkXw3f1DzlNVmRII+3 7o0RZbc8amlE8tkT8g9XXZZyFoVCp+I= Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-50e7af5f618so11972964e87.1 for ; Wed, 17 Jan 2024 01:53:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1705485179; x=1706089979; 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=/N7eo+PKWQbtdhFE2Ma1k5gF85XRa6NcuJZbycWLyxQ=; b=XEyDbiAkmn0kAuCztPqRhgG3IemkefygXqZJp3OiIQCWm6nstpQDJAWuAoS8tElx8K yIsa7vwOPOvP/xqiV6dSYYPdsBNiod2MmsaEF2PSnJCDOXbtfCPp5FqmQhfPmmidrBT8 qxeXYWnDA1rB3kdv+vExP4RSOnw0Ew2bQn/S/laZC3YBgIjGWrdw/x/53Q1pZIC1DvOs KhMbWE8JoWlbj7Kx7BOsd6/Lg54303nchTupX6G6gjNKpYLSuRDq3DGUID6B7SzwOy2i bNji30NWR0OkRfBDk0ldzbxTWqo7ndw92q6rszVIKhp7UMt1nYZiL5R4MTyIqzFFAerP k7AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705485179; x=1706089979; 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=/N7eo+PKWQbtdhFE2Ma1k5gF85XRa6NcuJZbycWLyxQ=; b=WxyZ7c36CrwtbU3/A3I3QDwcKxkL83HZ/wQQ5FWvLj/X9CrvDnna6OZIxeoDG97ufB ymDrJYxAeQq2acqUtlN6b2nNDyRoDEdYLu+xxOs9h9ibuoNjcYqRBZmr2VA6zOokXduU bj3gjtRiqcAUeP5/CPfrbK15iftE61I9fbfPATg1S6frCQ9lBdUI0lBQ+gqmqmQrVnnx cGB3uZVzA31CgClQySm9X1bkcFrWzxnmjSphiUzumNdHBJT4qVbRv/9yjN+TiYzxMTHE eH+HQPu6mgYds9swb/9wGykpgwsBzzcX9lQJkOjaiPqtmNX1yPHB14PHSL+pxhEbrdgT QRVg== X-Gm-Message-State: AOJu0YxlPdO9nUw4WNcdn7NX/0gQWrEhAVTQQHkBhO6JOj+szrDWmaYJ QLXvSIBlmNnDWkjPvdnltMnlJl3yTDZUgG9sOZmvSqrM6y2Hbn3yzgG1s7+H X-Google-Smtp-Source: AGHT+IGESudi8nDr/fKi6Timoneh+VJkUoh2CnGT6W9oVuH4EaQ5EuM6Bk113egIwSq/TB/qWmrYHI1LyLmQXz5HFVw= X-Received: by 2002:a05:6512:2007:b0:50e:dc99:b9d4 with SMTP id a7-20020a056512200700b0050edc99b9d4mr3538603lfb.44.1705485178988; Wed, 17 Jan 2024 01:52:58 -0800 (PST) MIME-Version: 1.0 References: <20231024142706.195517-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Zhongkun He Date: Wed, 17 Jan 2024 17:52:47 +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 , Michal Hocko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 056C740006 X-Stat-Signature: rdwp8hhoxim1x334wry3zkot9m15b7og X-HE-Tag: 1705485180-946975 X-HE-Meta: U2FsdGVkX184z0lC9qvAB2XWmt2YiM+jOMOo/OEQLTUOuXpswYIZCLmdzzi0TaU8738SBTPUIqzTsGi8Y3MkqdhBL8Yp6SrL0t2DsnoelwxibeoLU601bc2RB+HeustZH2rge0EsH0gCcgIDOp3da26qbqyhFBmSZSt9a3Si5sPAYHriUAvPL/kCrOjwwMYYUzjTLol59obDTRZQ0Iv85ZkyuJzDOVBlim41QhN5HqMd5VrKE9jYf2cZrSX2e+ERrTOo7btkEBhLZPWGH37lKzH/lyLdzRgO6oXm3K2rgWHwLRaILquWRZUk1ZTlyxSO+flNz/xt7ysTYjkYA7n66+GyJipDRUfrCsk91R9tnvoNiLMRd5HkRcKnWHusitvB5Wr1eFbhRCf4R1JEWJlZX3r8yWboxVWBypo8BMbcPjx4bE1VrJOJsNB9et8prF9a9M0QnWeLxbO/uBkJWwbNr9xDmzO3GSq4M056wKgjw8bywAQ/xUmR89VFCLhbONjx+Fr/mJa91X6fLLUJHNwOggGItAzdwyAG1jY52FUW8P5t4KZypT6J6L9WuMJ8cOiex7Inm2sXhgWOiulkvm413I5tESTfIixJWoFCLRS11qdrG39MP/pS+LihWNJPPp9wZmwFoTQH4fMhdZ/76/gQg5jhHjD6l0KBzA/DIJXzlaxUI/ySI+XcieP2QBeZ6jDtYCXvESmPGTSi4cYnTPASxL8K7ANSX9VwHWxpbu7SrrlMpGb+k9QzvOlKJkjdvrtirtbE9AH7TVs4zsqMQExPY4jT8Q+sgiTwNMuIG5oigi3y7D2aIb6ebYj50YWdl3ZAp7g7RCfvC3zXu5SyEnZTgG2l3t3rYqPLiP06U0top3j21O/Zm1zBgNMSQxWvxu4puAc/kMuifLHFg8Fc6PSUBHmlnYnInKjVD/8UuaTVfxxIcbrvRnizhv7q1XiRDgWO5jrwRDfwOYGHzlWug8c fdUiJHoq p079+MZFGsMko7meHemwpRDWHjzMjAyvpGMVGqgpvQ0pxBCgXWLLQEZ9/A8FM27eD2tN/xZc5f6BXosZlaq6qFR5QmgCntK9aRXkEp0lgvacFieRKvjUN+4Q13znVO8grv9LI17YO0jhYPshSQQdApAYCTloCH9kWMuC9AnfAwwgFg3BOVYqM+RNdd0tLIkteZDBm6QpBgDpnTZQW+YH+HdGDZv/tFo5aqLeYrbw1BOQkkSPz47bOog6g2Pj5swOf0rIlS7edLL3dXNxn8OaEaQtIccZ7LaRi7w0VfJSNtZ6asMMdbgzPRfyiDJzCO8K9LS4p47qsqjIMK0tV/yyx8O2ZAegqH6J6jQqCTi+Dr5QjpdTMnSqrlHbPMw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > > > > Please forgive me for adding additional information about this patch. > > > > I have finished the opt for introducing a folio_add_lru_tail(), but > > there are many > > questions: > > 1) A new page can be move to LRU only by lru_add_fn, so > > folio_add_lru_tail could not add pages to LRU for the following cod= e > > in folio_batch_move_lru(),which is added by Alex Shi for > > serializing memcg changes in pagevec_lru_move_fn[1]. > > > > /* block memcg migration while the folio moves between lru */ > > if (move_fn !=3D lru_add_fn && !folio_test_clear_lru(folio)) > > continue; > > To achieve the goal, we need to add a new function like lru_add_fn > > which does not have the lru flag and folio_add_lru_tail() > > + if (move_fn !=3D lru_add_fn && move_fn !=3D lru_move_ta= il_fn_new && > > + !folio_test_clear_lru(folio)) > > > > 2) __read_swap_cache_async has six parameters, so there is no space to > > add a new one, add_to_lru_head. > > > > So it seems a bit hacky just for a special case for the reasons above. > > It's a lot of plumbing for sure. Adding a flag to current task_struct > is a less-noisy yet-still-hacky solution. I am not saying we should do > it, but it's an option. I am not sure how much task flags we have to > spare. Got it. > > > > > Back to the beginning, lru_add_drain() is the simplest option=EF=BC=8C= which is common > > below the __read_swap_cache_async(). Please see the function > > swap_cluster_readahead() > > and swap_vma_readahead(), of course it has been batched. > > > > Or we should leave this problem alone=EF=BC=8Cbefore we can write back= zswap > > in batches. > > Calling lru_add_drain() for every written back page is an overkill > imo. If we have writeback batching at some point, it may make more > sense then. Agree. > > Adding Michal Hocko was recently complaining [1] about lru_add_drain() > being called unnecessarily elsewhere. Got it, thanks. > > [1]https://lore.kernel.org/linux-mm/ZaD9BNtXZfY2UtVI@tiehlicka/