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 DDA82C47DD9 for ; Wed, 27 Mar 2024 08:44:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5DF836B008A; Wed, 27 Mar 2024 04:44:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 58FDF6B0092; Wed, 27 Mar 2024 04:44:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 457696B0093; Wed, 27 Mar 2024 04:44:36 -0400 (EDT) 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 353E76B008A for ; Wed, 27 Mar 2024 04:44:36 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id EE4EA120B27 for ; Wed, 27 Mar 2024 08:44:35 +0000 (UTC) X-FDA: 81942182910.27.4BCF3F4 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf13.hostedemail.com (Postfix) with ESMTP id 271AF20016 for ; Wed, 27 Mar 2024 08:44:33 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kHhs8LrO; spf=pass (imf13.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711529074; a=rsa-sha256; cv=none; b=v9UXKALGChpHvQ3N3ivI/4alyHPGXuo52nbHzcl8vf9NyVAB5L3mOmwsW4R2okkfQ3+bwL psLVFOy2XPDU6VMhaXTK3KT6EARX6JwH7wijhVGv7Vryy+TqIiva3SCcqrPdgKg0ygAZMR 1syuqt44MLqiInI6onIr4HUt3sNWq30= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kHhs8LrO; spf=pass (imf13.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711529074; 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=4uz5bnic2oxtmsWA5BAWklU8JqMmbVCcFFbha4bBLzM=; b=F9o5lbj+xMG3cu/222gJgFRZy5MGD7rgE8cn1117jqmiip0PC69L1FKuzdy5xbCL/RbgzD /JgAnQJVQVsI54yF0ItTYTTI+a5F0RZXDV2z0FxJcInEW9xdda8iffe57H8pWHywpxVqfZ T8WajqR8yZtdR6YcAiLGQ2ON/aEvVRI= Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2d48d75ab70so91673551fa.0 for ; Wed, 27 Mar 2024 01:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711529072; x=1712133872; 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=4uz5bnic2oxtmsWA5BAWklU8JqMmbVCcFFbha4bBLzM=; b=kHhs8LrO6C+Cx9r/t2CGwpXih/FaF0LKORSJC4avZ3zC9/jTzIqamL+9GgBP9EJTM+ /I3SDw2W/GoeX/PDu9iaO5KDxBjf4/DK/WS+Khl8wGgYICjX6kCmM28l/73ngXygxk/I dpm4WuFNaAW+V0gtaiVpwDNFfTsL3qw0Om+d7EntWNE2AG9MU4GohwSabkeXYSaK24Ss wnLiCtvlSX9vKiLk57FlMwr+w/KjZelfn/aUpjWfYItJ9XOgg7PNiz1aQOSy4wnnvJw6 VcAjqqfK+PkxkEpRRB4bFbRLFmV4PP4/WCXXslUmBNsBJ6aKl+cUiyp/+qBIJWSHtcyF 0wgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711529072; x=1712133872; 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=4uz5bnic2oxtmsWA5BAWklU8JqMmbVCcFFbha4bBLzM=; b=CdZ7QFCkicDBvEVpamNlqbIKdGrlr1ckiJsS5NDdjHZRvypFKbtFha9lvEoGE86GTv p8wfW9alIKIKKwvuUBFCgzt5s+h+IuiJ3Zo46OOHpOlQLSgRFwS5ZMneUS2Plq+pJGUj NRGM3ms6g8PZuifDdA6F0sw0cDD62SpOK2fElc2Xo1xvemqATK9HeyDhBQHGWiTonaCJ ilBiFwlNStmN2aFOTTk2gOwbm4l5fRn/V1tnEny0Qe886PakpIjfPrWUFUjulbpXZY5x cT3SiTxda/+Or2LqdedcQsjbVBOF8Qy93OKyy6PJjMIgFDOqVUehornqR0MviSqY4ZKR D8XA== X-Gm-Message-State: AOJu0YxdPO7bdFSteiMK4YlIbiIhMnjzAJJerumH48VRHS3dvYAqP0la UcUnOktIfx3FMmwSo3XDNkitEbvmZKXaMIG1+HRSlKlRYMOwOIAdeKGW+CBbAm97m2GpHsb3vyX 8wXj/Irdwo3sgdYTe2tKpZ4lQPBs= X-Google-Smtp-Source: AGHT+IGWv/UtqTfqgA9rB7SSbcnXfmff9m4vwCHsdDmAIZSbhaetzgTCgXdXF0d7/hfmT/mG2l+A/SmbSPiv0ac4z3I= X-Received: by 2002:a2e:3c0f:0:b0:2d4:7870:3b50 with SMTP id j15-20020a2e3c0f000000b002d478703b50mr2236382lja.24.1711529071985; Wed, 27 Mar 2024 01:44:31 -0700 (PDT) MIME-Version: 1.0 References: <20240326185032.72159-1-ryncsn@gmail.com> <20240326185032.72159-11-ryncsn@gmail.com> In-Reply-To: From: Kairui Song Date: Wed, 27 Mar 2024 16:44:14 +0800 Message-ID: Subject: Re: [RFC PATCH 10/10] mm/swap: optimize synchronous swapin To: Barry Song <21cnbao@gmail.com> Cc: linux-mm@kvack.org, "Huang, Ying" , Chris Li , Minchan Kim , Barry Song , Ryan Roberts , Yu Zhao , SeongJae Park , David Hildenbrand , Yosry Ahmed , Johannes Weiner , Matthew Wilcox , Nhat Pham , Chengming Zhou , Andrew Morton , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 271AF20016 X-Stat-Signature: hmurnrzphgubo8aqjmkqyd4zxra4yjoh X-Rspam-User: X-HE-Tag: 1711529073-352092 X-HE-Meta: U2FsdGVkX1/geNaKFzuoz5PL2o3E1gsNpGyOpv/R5ZKTajrHKcAmfTi6ZsOYZ9TNFStHxcRkftdYBl/X537lYUhc9qWXH2FaHJfnSgiYl8s4Zh70ui22APnp0jt+ZaGchzUh/2nm0yR+g68fDvL6ybAIBkI5OyFOg+8k6MrjB/Ws6beGmuB5w8kxjDyTcK/2VKOymg23MEnrpRA13p2+UyEnvQmMm1Y8XB/rwCEJpHpW4kOHiSIn+HccDsyIYwn7TF9hFrocthqXttGGi8cypXi6hQjPJxgY+wWbSphbJCiHEtEHiTHBYA1Sr1RPF+/KECJwDbMCJ2TZEqa4YfToqVu7gEpwFPUpb8JeYJw7ZuArCCn3+T9vdH+/zU3UEKtx+X94O1+1guyJifPg959buyjzuoHLGxW32a+lqI61bL3YGd97zNWjj6DIcWENC94zkILYW1niBxXOKf7v4+hIaYbQNacLt05SHU9ayWV2lMuGZPSdWOFhsJ9No55bRbduCV39j4p1FQNdWt9tu38wfyh1r1uwNQlgQPRRopUsDsW/AoTKXBGv5IA9GjpJ4HsJ3CYeBUjlygmikTttNp83ffF4EmqrbsPTkP+hnEoUfrzunC1LFkbJC6icaORD2/ISmeLVvXj9USP7eopmxkWgXFfRRjQvsFDsiCVy2SU0jsaTnbniapqyPxdw9tI9zu/N4AIlnhiWnHvvrV00/wbk33zaouQ2bcxOzk+qQ+jOc/YAeMt3oTDR1WcjJXa+/a59xojMTHOosWK3aX86ihn9eGwsX7l+sUAs4Rkv79jrr9/OVNh6GA3HsyReKNppyM6GQ6ugvDmotwD8/MDpRxMvUkhk4S1dTcvUr0CiqKzOb/htyLYa8PeYJ+ZmRIvsu1OKqJ+82PVHZCBwv+JA0DnK41qz5996LVbKXC2wAFMVmQSK5qsN6bDbK8Q5IbDof6OnW80oeQowkvLMOihpEv5 EfwwFOyq Rx4MgKr9XSmmTZbgMTD4jhcFUTRRWcnp4C/5ZseYqsDsOw64Bb6XfnuLnGZTCydrNjEq6ZsYEdR3XAPLDiRvtfhLIvBULvHsa3lj6WzKuuyxhMuCS3Qzh+aAHB9rBNePrbaLVPsVzoicGJ/T+TAt7ww5CguQJ9GmRuFaM9ract7YXYJd0v4eNHWhKutReKLL94yCR+bvicObOHWf2po+kSOWLDFdYIVIHiDHSdYAiKezIc8J7siBigIiQ5ichMuRx9xCNdIgO+xBEsTgbrLaVChETq7pcK0m6NXs7dmuYV9mUJ3YmM+IJXnXi3/YmPb6GKN7a0IObw7WDH91esp6+rnY4TTqYiYZI1NRv/FVauraWJDAKbjBblzYU4tLVHRM3nzyYnf5RSAm5B5FeDGXLmowoDsVKotGlmcBvgit6JDYpIGEr+qzzHOvkBg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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, Mar 27, 2024 at 4:09=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrot= e: > > On Wed, Mar 27, 2024 at 8:06=E2=80=AFAM Kairui Song wr= ote: > > > > From: Kairui Song > > > > Interestingly the major performance overhead of synchronous is actually > > from the workingset nodes update, that's because synchronous swap in > > keeps adding single folios into a xa_node, making the node no longer > > a shadow node and have to be removed from shadow_nodes, then remove > > the folio very shortly and making the node a shadow node again, > > so it has to add back to the shadow_nodes. > > Hi Kairui, > > Thank you for clarifying this. I'm unsure how it relates to SWP_SYNCHRONO= US_IO. > Does this observation apply universally to all instances where > __swap_count(entry) > =3D=3D 1, even on devices not using SYNCHRONOUS_IO? Hi Barry I was testing using zero pages on ZRAM so the performance issue is much more obvious. For non SYNCHRONOUS_IO devices, they don't drop swap cache immediately unless swap is half full, so a shadow node will be removed from shadow_nodes on first swapin, but usually won't be added/removed repeatedly. I think the logic that "never drop swapcache even if swap count is 1", then suddenly switch to "always drop swap cache when swap count is 1" when swap is half full is not a good solution... Maybe some generic optimization can be applied for that part too.