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 862F5C47258 for ; Wed, 17 Jan 2024 19:29:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E6F826B0082; Wed, 17 Jan 2024 14:29:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E1F366B0085; Wed, 17 Jan 2024 14:29:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC0436B0087; Wed, 17 Jan 2024 14:29:43 -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 B7CFF6B0082 for ; Wed, 17 Jan 2024 14:29:43 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 76A30C0BEC for ; Wed, 17 Jan 2024 19:29:43 +0000 (UTC) X-FDA: 81689792646.01.77079C5 Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by imf06.hostedemail.com (Postfix) with ESMTP id AF7A318000F for ; Wed, 17 Jan 2024 19:29:41 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=L39Kt5Fj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.47 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=1705519781; 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=HwdOXy7SGjLb95yHRM4TBRusWdEvPGWfjIJ+jxRtxVo=; b=ipqE8LiH7yWb4PZK+kbyOuvsL+EkHQcIE6emd6/8uPjJHewKSqhkj9bIJkujYTMDprbz16 Vt0PZmLNSAmdVSCDgD5HdqJfOkV5GTwvINr/ZPK5XCSTX+4ckeeIOnEQO7FvIrGUC4AMj+ c9uLguScsgz3HZWt1igaSIgTgWyS56s= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=L39Kt5Fj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.47 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705519781; a=rsa-sha256; cv=none; b=1Z8gFkxY5XKSxz7+JoQyyX3mCaKZ/9mwt060w3H5/92315YOFeZkSJMgvv39eogZMq74rZ dIRu0RZdgcoywseA3HO3dodYz1jrH6EL1akIcCua6YUVywJs+/mZicpr3vKyK0vKAoYe3v STgSaumH1+k40oTjYRPqcXV6kJMSwxU= Received: by mail-io1-f47.google.com with SMTP id ca18e2360f4ac-7beda2e6794so295082139f.1 for ; Wed, 17 Jan 2024 11:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705519781; x=1706124581; 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=HwdOXy7SGjLb95yHRM4TBRusWdEvPGWfjIJ+jxRtxVo=; b=L39Kt5FjWB0vUpcLRQsZvF0X3E6aznoj+36qQvDvIhPlzSHB7QDAzE/SCsFpeDtLYr 7ixd577mp2ImJ0zVYmV92HJPj+YPa2ZkzSh8AcKdKdHZgJd6RoDiDEmzKJJzsYSE0x7t 3WE65JGI8eeGQHBoB11ibt14mk3mm1OyJVhauuUx6WZJI9YwSPAnm6JU6nYfjdTPY+wh VQDZNheoWrjUdaa2PhtIlbmirY6Qce5mTf7eDsdApaM5M7FpJw6rrJtyzkLQq/cjN1Wr 1GtGIod+vWw7Mxh9RSYJ+Rt3lyaXBoOKolBlSQUJf5pH/ypIru/qysV4wFi11PRs7F0K UdoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705519781; x=1706124581; 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=HwdOXy7SGjLb95yHRM4TBRusWdEvPGWfjIJ+jxRtxVo=; b=Znir4wEghADSSK6Rn+Ag/ZNBCNpX0956VbzHNKT0m20ybnBcXZBO4irUiaf+rs+fl9 tLE2/GPkJr3lFedIadntTGKjOBbJv/hhfwDI4xIOb9SmCeeVRYB7nRxC0O3EtJXPzHtv O0GKdHYTY6Wm79B6/rqNYjB8RRZEYnSLNZmA1ON5UNlaz63qIfwGtgBxMAr5SnE91are fA19Y9IYbJYL172hTD2saGjX68821qsQz/mRvgb6YDk7jIwnR0bAztU7xOXcTRq7vidX qvXDZnS3+Y0YwCAS3lg5870hOky2Y7+zkIAyFAT6dro5pAHrwRw3DzYcOH/Msdr677L9 RjAA== X-Gm-Message-State: AOJu0Yy9uKKjFIP4RWy83SQnYlkK9QdOc4T9pIPfceRok/obveRQ3xYG CGWaHg53Qan4z6cbNBvm3Vx72NYfQZbF8KnQdLk= X-Google-Smtp-Source: AGHT+IF+ZHy71HvFx/DWrxMtc91jGIFhsUoG/dWbvXmmATBmGxQTh082HisPIy+9T23OzDXsqA+ntB9TKizShofqL2Q= X-Received: by 2002:a5e:d91a:0:b0:7bf:5355:dd23 with SMTP id n26-20020a5ed91a000000b007bf5355dd23mr916618iop.6.1705519780874; Wed, 17 Jan 2024 11:29:40 -0800 (PST) MIME-Version: 1.0 References: <20231024142706.195517-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Nhat Pham Date: Wed, 17 Jan 2024 11:29:29 -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: 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 , Michal Hocko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: e6btxddksrbzc8u9hyrhw3nirrwfwuwa X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: AF7A318000F X-HE-Tag: 1705519781-446221 X-HE-Meta: U2FsdGVkX1+LoKlXMac4mri2q8B8hvc4gvRZ3L7TB2FEp9Ihtft8fi3zaLdN6iLUPuPR81NELWzOzk5lg6itiTK+p6b8JbObnQLKm/JOIxZK/sH5/GfRiy2s1hIsjxeKlTVzVAqtR/0W7LBc/jNoJLh0RT1gw/CXNbLlUamgsRK8v0G26C+p/3aaPQ2nC72Da9ywhQTWj/V1Oyu4Lbu60DUI6/1sFAUOU/4EK0tgZNKczke0wegkigghjirlNE39BBT5wMTACAOW+v8qDinEgTpKGyAAo6AnsgjqG3DrLmQ0FL/NDKKmJhNyJzNV1vDe1Iy9Cu+ejgtQsta0g6OQQDCAS4KNpQ+rBuYyNZoqVcXDC8YwO1gXl2mKV3+zQZMQAlHnQruiNVzaFm+BD1NaDS35/tkPk4G1Vraug3ZZ6ayZeH2YVZKqgL2wuq1pDc4W9cvXVTZr85yJNk8RED9f4T60EPVshL1ao/6+CeJqsO9MSM2XGxAyg1pkQ9xhlZaBND5RTi0PABzyl/73q86lMUP2jb4W7r00cjxUQX9BwH8ygg4R5bM/K37ikKJ7KYmGnVhw8yaS5h/+z45xt/rauMivPuqDWEtKLjMufjOOHR+cq4deukisLe8CNfzh95L8eiDL/bTlseQAqSGOW6JmF9OVxzk+ZBU7ssW2CAPje1CkcDG00nSyzqHN/i+cEASgb81Y8MWT+rkgOznvg7Dq0iH/IyfeMlsE4mMgcZeWdV8ULNbqULifze6H4nuzolUWY4s8Eqvat5jYPhVTgIX1qdMsYtylf75rsy32ILdOROU8qcNRtga65nnOy+RhiZzVHO0VnJKAOFhL1mWAXCBdR/7rhpk9IcBeJzfQaqgdPZirL3OA8S+0nO8mn6qw/Wm4zKh6znQTvM7+VG9Tbz/yCrkxwUrMaK1N3N+moL3KChl9aJ931hgX7Wz6AEicF7bkXCLJaoUKHPhHQ/WLg2r TPrSZV3w wpiTd/8G7mBDjZkWODhe/6x9Ncw3tz17bL8Bw6lAEqLvHZr5lRve0MOuJ9J7o4YSM0S+Pa0tLUfixS32CUlfOEBXKgJithzScddlgDq258L4QGv98GOR9uNC/mL7WxgTMxPu7svTDKS3ZYUsx5DcJD1MhQrrOzc9Ci6gdyYGmdhuS44KKLJy1+xoxm4WyDQ2t6tB7AulvzvzUHEOS2I3C4TY4ooVIfLzx3LbnADuRJUSj4UkD4ufK/j9wqjOa7tMMkCKe6A+0WIRNRWxSio+44Zx4ckdJ4xdunh3pqpgbO5UuPKHvxO/yHBUXpCesK49PwsoI2Xk3XtUQmPam8tIFmhpS5W9ZUsRQa3BOkjvSozUl6eRY5yNqW/z2Iz0QBQ5f+RP1VxcFJpgbKBFYUroRkwKEPWTXetyE5zynYbjYn9jZWO4+1iuOHgqZkxQB03/9qOJuJ5mCIMcZZ7I= 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 Wed, Jan 17, 2024 at 1:52=E2=80=AFAM Zhongkun He wrote: > > > > > > > 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 c= ode > > > 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)) Hmm yeah, I guess it is a bit more plumbing to do. I prefer this though - not very fond of hacking current's flag just for a small optimization :) And I'd argue this is the "right" thing to do - draining the other LRU operation batches just so that we can successfully perform an add-to-tail seems hacky and wrong to me. > > > > > > 2) __read_swap_cache_async has six parameters, so there is no space = to > > > add a new one, add_to_lru_head. Matthew's solution seems fine to me, no? i.e using a single flag parameter to encapsulate all boolean arguments. > > > > > > 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= =8Cwhich 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 ba= ck 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. Agree. lru_add_drain() does quite a bit, and doing it for every written page makes batching less effective. And as argued above, I don't think we should do this. I'm fine with waiting til writeback batching too :) But that will be a bigger task. > > > > > 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/