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 25E76C4706C for ; Tue, 16 Jan 2024 13:40:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4AFE56B007E; Tue, 16 Jan 2024 08:40:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 45F696B0080; Tue, 16 Jan 2024 08:40:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34E626B0081; Tue, 16 Jan 2024 08:40:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 201AE6B007E for ; Tue, 16 Jan 2024 08:40:22 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E85191C140E for ; Tue, 16 Jan 2024 13:40:21 +0000 (UTC) X-FDA: 81685283442.24.872404A Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf15.hostedemail.com (Postfix) with ESMTP id 1A751A0016 for ; Tue, 16 Jan 2024 13:40:18 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b="JZ/I7cYm"; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf15.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.43 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=1705412420; 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=WVJU5jiTzPEUoyMMg2QyayUMBhCdBnwfYp2MyeRq/z0=; b=74Vn9scI7ZEp+0d7s4oovvn8SF4SZr92Hta8tlslDAZchr+azGVZEmlgpNT8ujRv+JUdWD cfO4aGE0EgB6cZUTCl32WK4AGTrNjDMEwjadE2vDHNvq7Gefp4AewaCa7lhGAXFMrFYx4w iYzmzOCHqdLtCy3MNsg8qNkEViTd8NY= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b="JZ/I7cYm"; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf15.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705412420; a=rsa-sha256; cv=none; b=3xzQmgSQMSbMn1AHBg1YU7N8C2+ncTeSgIZqDZV/57lBc1iswq5+mQlskBA74J47pxNbzx oEZCzOPsPsj8PEA/bD4xLdBQBRlnqF2TNbU/YEjFnC9nBMV7/AbH3noH+5gG3sRWPasXKb SKnsny38bT82C09VX+AwfKBJoZOZ6ew= Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-50e7abe4be4so13165814e87.2 for ; Tue, 16 Jan 2024 05:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1705412417; x=1706017217; 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=WVJU5jiTzPEUoyMMg2QyayUMBhCdBnwfYp2MyeRq/z0=; b=JZ/I7cYmPG9GjnVyFaNs+tqWB9WZMfE787768zNwOaXsetw4h5xGrdgL3lj0qkQDLq aIite8gc8sARHZrnwyDEiNgFCZWrcrZDZ1qSvM5qynPQF5vqZ+k7GCWQQJ9A7PnGhtBv 2H6ygDf/yVyghB8MqzuvG3WeDvp1ea6dYZGtKOe8hENrgDyAUVZ7Mdx+kT3fkVY1ypar k9bPOPk5idYGBA8XJtR2AX6ZcCfXuXEGb/P6PTX1szuzczmlCk6cZHQWk7Q1hZMSVyOZ XCNk24A2IBC9zMLifyWY7a5kqKWBbZQBQJcf83nG9Qe6EPxvZXiaC2VEs2HZ6OAwTp4z YoVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705412417; x=1706017217; 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=WVJU5jiTzPEUoyMMg2QyayUMBhCdBnwfYp2MyeRq/z0=; b=mesGJ/XaNgv8+dW+DbMgJX0XbsmOjvWZOu/kFfJEGmRM23O1et6WEGKVZH4gr9VTxN Gv/aDYikdMWgi+Rif+GuLOCbFZGaFIk8BM4WmOJaHugVZ9o8NShnEjRxPYYPItOQGR+2 ED63ZfYWT6kx7P6jcGl1zMozEze/wVD3mkkO6fhxakwV/3s9SQ+hOZDMZavjaTouhW3/ Q183VGDnwuFHKK1n0FBKqfmMZZyyqU0h/ujVvCZVruUT4HhGvrEV9qIcq/TlLQhB2bvU OjINwk8d3kFYoAnQeeek6NXF6PtOl1QOaRzI0CahyaQLWHwpEpIETOsddSPN9OeZxwsV ov5g== X-Gm-Message-State: AOJu0Yxikvtr08oq1cWPEReY+PIk6d+EqcId63bvfjfDoDX8kC9eOV8A V41b/lCMNBDYty8Qezp2aQlVqCxs0ZpBZ57XS7wj/cC6q1y0XA== X-Google-Smtp-Source: AGHT+IFnnDAhbGcdZty5D9K7fUTZ8B2Sp+Dbtz7dhqILgr6F04ua8VzWoNqKAww00qzCchYrXjpXF5EnABZT6zCkVe8= X-Received: by 2002:a19:5e18:0:b0:50e:6d4f:6915 with SMTP id s24-20020a195e18000000b0050e6d4f6915mr3325240lfb.47.1705412417104; Tue, 16 Jan 2024 05:40:17 -0800 (PST) MIME-Version: 1.0 References: <20231024142706.195517-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Zhongkun He Date: Tue, 16 Jan 2024 21:40:05 +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: Yosry Ahmed , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 1A751A0016 X-Stat-Signature: fu1u4ro4e636e43etrazxkz4q85adsdg X-Rspam-User: X-HE-Tag: 1705412418-731778 X-HE-Meta: U2FsdGVkX1+p2KjynVddIlOz/vMjMIbhu7gW+bukP/qRr8X+uDgb5/pgtrujrWeq48DRMG/svmKpZmVarqTUOjT6H7+s+S7jAe3b6aPBf905ZKj3GTccztEXOJJtrJu81bQNRA0GMfNaqKfe7wfRKRf7TqXqlTNifAD7SCCRc6DW/B5d1xRNp3RFi4IgmyaIP+5TWjoEN2GPrI6XTzPdNrfRqSOwk6jjPsNn8m3iPTjqmDmgfCmroeYfNSXo3nEDkExHFmAvZIRF0Q26IJ5Kn3uhOmlZe3INh5jvo0hKuwKRZ5p/affqbM4VrQ9XPQ6hK23tux0U0hR/o70AaFxeUddkvcMzYxs9BHrWGhcsmE0PC12Mty5ejeGziyMXe9gVHKQ0muMjQ5NYVl7/txQw0UL82tAhlW4dgoLMLzlsdu+dg4aZWxJqUU+96ZA/x0VLUBN9nzEAedC0RvWHxwgahxy5CQ+KEEFISUIs9+8hoK7EqbTgi8pLi/itadkBdjWFEe6bjZHc+BqU/0nJXklzP7467jc3KtCU2pwwWh4RxIBm2KiBmRDYQtDIw3prDBjCLdaQkcwnIF9Zv/rouZblD2AXjqxNXDqih51KwIKjmZy6qLyO6qIUCtmzQZBymVnqTrYnfFaTSvUBBCCr6LA9G4a7+T12/lHpX50+jdwWjo+mG4+31mecTxLkuaGB6ukFX+oHUxsNrWZbZoV42xk2mMH5CAJb+Yhh08h10ZWUjm2v2YPwu/mNer4nG3AswxQX0592/AaP3pI6QJKjBvLC5xz4awQOHwvP+ZYiIE/YXztjQ3hRVd6rRKdYbHBAFKc4nJWrz9leFfBphgQSf7QzN63R5aaULdqBdmKr6KBlJyzQkhkWYoEzmycAlNwdCE36NLv0WkavJcCOmk76HVxJ/MUPm+hydUEfUH/RLt98wnPSf7y9yhstSFYZDIG+XtsHEtwq26h45TrPKNwHQKu UbByH9fd bjLVKEGMWujhP+s4bOUACgqDERSmj7f5svnChRBYSjQB2dhxNb0ZzjSJSyAWq+SvRVnffEPWgvN8m07JvZrCbE+Iog6YNIMjWyNSE/5XSnHk/Sy2nRls1Ai6OFKNl0JbzWi2N1LhgzJY6383YzzMrdaZPf4iu2WYJrFMfYkQlp2RkXbkZGIdOcMAZpmciY+YXXp/tHZZp0vBAEUP0HeKJ15eX4V42+lrNQE0jVA5s6850f+K60VCrMEN68+3iV7sAw32Oi1kfi85xj2xtb1ws0KBX5Kj0F/7bYXnNzCQM3OxiCKsfB+SrFD+Ox/ovKK91DTxB X-Bogosity: Ham, tests=bogofilter, spamicity=0.000023, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > > > > > > > > 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 mini= mal > > > > codewise, no? Just a bunch of plumbing. We can also keep the other > > > > call sites intact if we just rename the old versions - something al= ong > > > > 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 *th= at* > > > > much more work. > > > > > > > > > > Yes=EF=BC=8C agree. I will try it again. > > > > Look forward to seeing it! Thanks for your patience and for working on = this. 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 code 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_tail_f= n_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. Back to the beginning, lru_add_drain() is the simplest option=EF=BC=8Cwhic= h 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 zsw= ap in batches. Thanks again.