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 80AF9C47258 for ; Tue, 16 Jan 2024 20:29:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0270C6B0089; Tue, 16 Jan 2024 15:29:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F19CB6B008A; Tue, 16 Jan 2024 15:29:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBA3B6B008C; Tue, 16 Jan 2024 15:29:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id CB87A6B0089 for ; Tue, 16 Jan 2024 15:29:27 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 993251C0FDF for ; Tue, 16 Jan 2024 20:29:27 +0000 (UTC) X-FDA: 81686314374.17.00A8800 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf20.hostedemail.com (Postfix) with ESMTP id C7B631C0015 for ; Tue, 16 Jan 2024 20:29:25 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JONHbNxG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705436965; 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=xlVylpwq7EHMoUhpeUYxVoKLMBZq2evpSqBt9P2b8io=; b=VjXwR5CYuOuYnU5efciZkenfn+ySlDwHjYkBOidLGmrPGRiSkjL+VZL1wIxHsNKMx1HqUn 0yaRngey9H3d8lFMqpX3VkOFHB6lExs/peP/EBWbtOAec+g6ffNvlq3qW51YhTWusx6Wsk KUTWJXkuw2GN6ZGDHvBGBfTIpuivN/U= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JONHbNxG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705436965; a=rsa-sha256; cv=none; b=HmskE584MxeEcISI6AzzZyX1hmmnse9/mb5h2E0HNnm9aZliZuC9zinAOvvDYsMMRGer7t iwqMCAQ1Zds6sK4YE8lnQ/fC4gteC5LXPYIg7t4Npticzn4wa6n+uaE8cgPSAvlFZVTZZ2 siway7oJv9K3AvHitfmY/D6U27iWusE= Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a28b1095064so1161593666b.2 for ; Tue, 16 Jan 2024 12:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705436964; x=1706041764; 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=xlVylpwq7EHMoUhpeUYxVoKLMBZq2evpSqBt9P2b8io=; b=JONHbNxGYMQMuwbybOvEnWTWbQdeImBjrxJ+f5irbxdk5WPz+9nnOYnQzw+pYkOXBe Sp9q5ZOVXdKk2D4u/pLZxD++iT/8L7kdACzBoiWSHVZXs2AVmI9hm4VEMbI3ENLOCnGs NVI7s64EXAmhh7UDPZixwfvMIxel53vZIyBJvvMwr+VPeG/Un2HfKb10l/iN3J6uljKa iBeF14PSoXQ+nb31vqJv7B7oLNC2mXIfqokmfNafQfIjDHfG7JDm3gb9FXpshD2KbMGp LdAx15aCkhMl7mqgJXUR85FkZwgAnWowRN3iMVswrb2Zq7EakSQiZi+OiRONlZImkbEE oUdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705436964; x=1706041764; 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=xlVylpwq7EHMoUhpeUYxVoKLMBZq2evpSqBt9P2b8io=; b=drbLFOascUcxFZo9eaKZuJz5UyKD3rDQKIZUcaWED9RHN0rJRPZfW+9XzUzw41tu3d ajcDuocK5PxS5iJPc+XqcRvff8uGryhNooNZCDC7V7SPmzguDGEj+Wq+XBuk18c+VBC+ YOTRlLZ8clCWGQshRkDOgTyhz+ycOHgH8hTqtKVfMUGJj8fn6EkOSzdIYmVgBJAxMzuV 5ZsH+T1K2lBaF3/lKi7mJ75OXfxofxYIWQlPTrddrjUgumwJKElGFOosc53Z4y4LEHpV 24ozQ7Rjh2pcsEe9DP3im7OW8q5uzYIu8CDNyfWaL0FzxFuMQ+g+YgRN8eEIz73hZT+j f5Sw== X-Gm-Message-State: AOJu0YwDUQI5u0pXsO1XmSUgIKI2NWVHd1hkYacVFKq2AcAxLbc/RKhs A3660TmmprScyGw8cnnEjoAklP/32YMEY7hySJ85qTNG8LOP X-Google-Smtp-Source: AGHT+IGmdi+XOz4E+uUCLfi66st3ymRH99QBHes/4q8aLhSjqZmqqv1KZ8kwORV6KDYGoH3VENm5TAw+h2FB4HE/+fs= X-Received: by 2002:a17:906:79c5:b0:a28:f771:aeb2 with SMTP id m5-20020a17090679c500b00a28f771aeb2mr2063045ejo.180.1705436964172; Tue, 16 Jan 2024 12:29:24 -0800 (PST) MIME-Version: 1.0 References: <20231024142706.195517-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 16 Jan 2024 12:28:46 -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: 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: rspam12 X-Rspamd-Queue-Id: C7B631C0015 X-Stat-Signature: k3zoqnb1wfxkf8p1zpj74y39xmn19yyu X-HE-Tag: 1705436965-532843 X-HE-Meta: U2FsdGVkX1/r9r9jgkreI4Xj0cQxGE/C+kEKUghPU5ALqZSiGPKT6DXeW+Q//hXd0ddMkHjt+JTNNsZx/HngOIZxUtVhiswr4heVXtZXqMcdT8lv/kesrxEEVB7ViWly0PURKwRkHXYzz76CBb0Kei81tYLWlBuuWWIFc3sbhzqUZKV+52hGdA8tpFqWGDesuOZUcLaJAW8v14jGunafhiyHMD7ih1/kzRK5RZTr1SxpG8K2sLIwvuIArPcDbCYCEsf1IltlXCO8m4yYJKH8JTqyCWuQ3S0E+Pz1K8tHmRv+nWHuH2lkaOGGSmtO3iueH5+8p5ujFKK4W87yNsd1lH2otetbVJoVpYClQfsnm/ezTsR3fC7kaKrGf5piOeRGSWLcSHxjWdZxsmIIbOKqWpUof895BwlrHV9bwPZL6t+kx88qI2lNjkQfiWn8fo9aYXTozVLKnBi1dMwmVzlJ0scHphJi9w6hvWyYFkUZSTj59iq4q8Q2NwBchQ5dASDdofhhF4MLeOUNUHh5blGX3vBp4I4u7KYqA2miAl1dQltMnai2t55+nILyl9WCXzT1/ZbqIQmEHYHBxuAXX8qWc7z93Qda7kP/0xkzUqtTK8JIngjKY1M1pS87HIxpE2cOdPDhb3Dn/36MI1MnL4CS8mSVV60v1Kfvc3ScruZn6X13Wc7MzVhOvcbdrgNIsx9C2Ol6hqcyg5qpfTsE/M5XsXmEgAWQhjd/a+bcZpXV+DWmA3EJ1z+F1VZgTaY7V6x0af+9VAsw9updtm2VUATwoXo51ULTnmfok3dSPU8bKFcoATTCWGtaW3dxX+3M2YiwQmTiGB3cx+LFhKA99maNmUr7jopAYFasJxEnItyUNPCLj2E4mWGaaUO+QeWbnC+k8/1PXEKICpgZunasISRazygZyYKc6gc7eF0JsvI7iYtADC3vg4NOEC59fdRNfzV9FCQlud3mDSU3JTGld7I Pcg5qc71 NK+i6a0S7v0DqnzNvJsLXfGSd/NjXOXWVWsyAr4r1EVb6C16P9EUU5DAMPSAmRNv2cdnPaywy1YK2Xk6FGL+Z/4BcD/+mVH8fzqV/l89PqO2Bvc2tNvUAnydTYOWrEmt1w9j6HUfKWsi67MbBD0XjUgBLmapQm+l3G3W7VbTZAFBR5T2GHN2F5nsNQ8a/8TBGb9GS5t9ErJET+Y+eNLgnqbkChBSGSIg6aLmuyEOSMBJkymEOxlTZqDm+tzjBMRKLoBaYsgE4Q0E9+vIGd/whijcgv4O1xc8gyiysEZz1FTtfOsynhEsBfRlJs6pgKLtuQQXZD+c0BjkhkseoRHBGH317RMTe/eE/FQ9K6dQYJDStBUiXX8U0TqcHq7n9F85/PuhJ2UYzvMIdUaiPiCNQMwmyU8/gIlA+mu9B0mq9L8EqFZw= 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: On Tue, Jan 16, 2024 at 5:40=E2=80=AFAM Zhongkun He wrote: > > > > > > > > > > > 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 mi= nimal > > > > > codewise, no? Just a bunch of plumbing. We can also keep the othe= r > > > > > call sites intact if we just rename the old versions - something = along > > > > > 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 *= that* > > > > > 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 o= n 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= _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. > > Back to the beginning, lru_add_drain() is the simplest option=EF=BC=8Cwh= ich 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 z= swap > 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. Adding Michal Hocko was recently complaining [1] about lru_add_drain() being called unnecessarily elsewhere. [1]https://lore.kernel.org/linux-mm/ZaD9BNtXZfY2UtVI@tiehlicka/