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 B51CFC47DD9 for ; Wed, 27 Mar 2024 06:37:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2BBE56B0082; Wed, 27 Mar 2024 02:37:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 26C3C6B0089; Wed, 27 Mar 2024 02:37:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 15A696B0095; Wed, 27 Mar 2024 02:37:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 075BE6B0082 for ; Wed, 27 Mar 2024 02:37:48 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C589C1C0785 for ; Wed, 27 Mar 2024 06:37:47 +0000 (UTC) X-FDA: 81941863374.30.0AF6C56 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by imf27.hostedemail.com (Postfix) with ESMTP id DDA894001B for ; Wed, 27 Mar 2024 06:37:45 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Xt7/uNM/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711521466; 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=9xRCZV/DoCsl1IXRPXRF8ryJxeBYrzLKPPE0aKQ6Epg=; b=IQjKrHcISCxF4+MHnQzrTdl0ArHsMa9bqppOAJj1XCDl/ylsqVQ28cuKL34FA/llUtEucx wQh3rTjvR3lJYQzB1G5IJsbRY7ieizuuIXgAGcm3IlSrWi/JUU7mN2Pu430hXH0uhvnqK/ 4SiVQBx6+wk1jAyDpGFjDy0+DPYOtB4= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Xt7/uNM/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711521466; a=rsa-sha256; cv=none; b=PWvMpQ+AfpgBeMwG3sJlxsv+upiF+IfcC2COLRscGIJBvVznYKiol862/2l3Jc/S2ROTzH y4Geh1sSx1T7aEzC425dJxJ0g5nLj2I0/dOvvAEh1LHKvXG3wd1kXulTxS4LtvPpUwa7Bv +19dlpGTN2uxVLnlJ3R8GLE1DQkvXXs= Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2d475b6609eso79252981fa.2 for ; Tue, 26 Mar 2024 23:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711521464; x=1712126264; 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=9xRCZV/DoCsl1IXRPXRF8ryJxeBYrzLKPPE0aKQ6Epg=; b=Xt7/uNM/rNn5qfai7IuLvOgodl6d0fYyx87polyKSzjvZ47ypsy4Yx6T2MiEn3a3Bb 45+qdRZLgCt3/a9YFpYmgNU5ZAD3dh+WTqUaAocNgWgraoVtetERaFY2qLoQWWOBm1uM 6qARseouel6TAV4pGamec/Kr8M7aRyvG9DzRcYiUVkxc3dit+Xr6z1diii/PHQS9SeyK zy7iD4l8MGLc7/Rbml1Fnl822PWjKvUJs5ey2pt+cSrOJn9L2zWYcutGXuUMM2CRDSXn JbeFdAf1A12ZWvksUE1ONG7+pVL3qUa1R+aTyEyeirXYa+s97enVfamJIQBvB94zVL+d huRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711521464; x=1712126264; 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=9xRCZV/DoCsl1IXRPXRF8ryJxeBYrzLKPPE0aKQ6Epg=; b=s5crEZ9+cLQkpuB9lO6UCcwIAPOhvCos5g4C0eo6JbMwJNumCtAc2mD9aH2s4wKH5I Wbz4r0J9OX8b/QFduGA0rdaUTo8f0mt83EzL2VI8ZoMcs42D0wgD5A3S9Y9wysHCEouz MdNcqgWQWyv+z7t+GF/woWS+JXgo4MrMzh6+aBuB84/fUxKjR/UkGAvjiPEY2AjiZZnl q2nAIQBYIIuAEVXPb/hOIqVOkwF7QbfW3EX9X6R8VsCtQIi6+8DYnSfYBqz2btFulvBg Mp7BXBEEu3AgHTTjURylx01P3N/5cu5VkiW9MsaecbbMjbCM+O0INBoDuat/qQceiPdE wyAg== X-Gm-Message-State: AOJu0YzwDqVI75J1XWCq1kxY6xD6+ZwgNJAdCrYzjcFejmwxPbVOupjw 61KIdBaHrxnl80ZxwfE50eK/8+XgbMvwJ2OaDmBjCCypMdQfNyVpvdHwtnatLH1DEn8o3mtWTtV pv6nb5RheF/zqy6luHJEXvAaa09o= X-Google-Smtp-Source: AGHT+IFP36X0x7Y4uIxFOLg/TPs4cMecmv/NsfNrKV01BYoqzbIV2D9iVtA+gZVp9VkMB8P0uScAIOQQksOhARs8EhE= X-Received: by 2002:a2e:9f0b:0:b0:2d4:aae0:1d71 with SMTP id u11-20020a2e9f0b000000b002d4aae01d71mr226051ljk.43.1711521463657; Tue, 26 Mar 2024 23:37:43 -0700 (PDT) MIME-Version: 1.0 References: <20240326185032.72159-1-ryncsn@gmail.com> <20240326185032.72159-11-ryncsn@gmail.com> <87zfukmbwz.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: <87zfukmbwz.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Kairui Song Date: Wed, 27 Mar 2024 14:37:27 +0800 Message-ID: Subject: Re: [RFC PATCH 10/10] mm/swap: optimize synchronous swapin To: "Huang, Ying" Cc: linux-mm@kvack.org, 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: rspam09 X-Rspamd-Queue-Id: DDA894001B X-Stat-Signature: znj8cbdozewg4r379473n3ksfmugsmpj X-Rspam-User: X-HE-Tag: 1711521465-129862 X-HE-Meta: U2FsdGVkX1/sllfBUkB0qDixNVAeFWfLAA5ZthDF4zumTGbNZSBk06TkwBGvB6SHVbS0l0L+d1HFIgE/vUZNsh1n0OmFOlSESfOxsWVtk4882oyVBJ6+xOku1U7uxAQBTjy7ukyhz1oQiM3A0Sj1ps8LIiTmpLtDwKxADm9R1kX0zwQUp8L3R+GgOBtjONtUXFuimtOgXz50Do14A323fxYYK8MD2DD+UU1zI+oiHCWQyfvOmXP5miu0zKeeKmEkwvmY8sRbH5Rmq81re+GwmLw5Iev5mBc9ZKLaT+30RO2kx/gEzxjYpgvS+SgkO0for1xtrx8AXeMj1bWi5EizpgtWT/kRtx2Mh/yI3jLg9X81nO4IvktRgZxsuILBu1HffCbVSEfxrpCZe2D2r0azmmcsluggUNr7ep6t38yj4ExNEIY4U+1w0IhuTT4CZLdhMNFOERwbh2cLNK1p/9IyCy/BxIOKKlUx7+DmeUjCsVSDR7zzA5+VNzBvVzCY8pU05qOCMDhjRpRttjZ1UANjaDxPDlP5rZVLkaBCyuFDvb95/gZTWc9DHON5c7mfSSmJ7gmZ7wYPEuoEmkKrobIVosAr0YuSaiWZsOeDfs9jr8CIRzj1jCcFM36gpWwtvEoRLDMQp2j6mn/u5D0AykMaUEjK39TFpNms2YnLcgVqJ9K0K+U1bTdFXJMdpu2mnp2mCbN2oyDsioc1+t9IpsgKQX8byD5wm4rtDHA2L6XN2S7i23fmcMolFsJBGzRSogOVDJvqphOFdd8FC/CtPDNRCrVbF3MQcbcHUl2g2w+xzGSuo5hvLIRGP1HunXm7Q0F1kmzEZxcmjaPmgXuLppbXOFHE5LjHvGc5Qi6tYryp6ll+agFUKcoRF2+2OtIdThSnL1QHuVHjwp7GmpNtsOlog/WaWL6KZO4ucquNzY+QLWHMOp8jQ8ywGWTMSRKbKkHxzfFjVH/PUTVDSJRj27J e7ApVb7R c5P+mZ1zxtk7KWxIwqKAz+mkFoIpcSxUZmUBTf8CSgBZpIhyusDuCgjCc6+yDGLag6pc/ZZL2up20CiXEFfeVe9kpYuSHNcVtddcH2tOjV/22pcArkffO1VNiYnoSmmMFEPpI9fs142ZckJq+KJcIkKSMr3zIY5inza66XCik4pxHca9Okf6+2dwNuHPVrOYDCSf6lBcXHjWXIoB7LzD/5hl8v4rK1GVzPs7GpiuQnN8sb1oD3EL7TjN/33yWehQj5VqKAxpnwcc7UJdhXDF+TqLuftqXoMZ6m/LQux9SUBN5gcrCX0028mGFVWowmKqjkDI7gqHTV5oETCULxBK7pjEGN5dwzywd97NXQ17LzjzT2Q48jPC3cvMeG+dC/xKlZm/KMZezuXeCxLSPvKruTS0PAy92FdpZIJxEtkrGT7c+H53qv2h9ub7aagIVp4/JGuBT8V+vqDDyTWU5+yoWoDqnmQmA9qz7sbSh 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, Mar 27, 2024 at 2:24=E2=80=AFPM Huang, Ying = wrote: > > Kairui Song writes: > > > From: Kairui Song > > > > Interestingly the major performance overhead of synchronous is actually > > from the workingset nodes update, that's because synchronous swap in > > If it's the major overhead, why not make it the first optimization? This performance issue became much more obvious after doing other optimizations, and other optimizations are for general swapin not only for synchronous swapin, that's also how I optimized things step by step, so I kept my patch order... And it is easier to do this after Patch 8/10 which introduces the new interface for swap cache. > > > 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. > > The folio is removed only if should_try_to_free_swap() returns true? > > > Mark synchronous swapin folio with a special bit in swap entry embedded > > in folio->swap, as we still have some usable bits there. Skip workingse= t > > node update on insertion of such folio because it will be removed very > > quickly, and will trigger the update ensuring the workingset info is > > eventual consensus. > > Is this safe? Is it possible for the shadow node to be reclaimed after > the folio are added into node and before being removed? If a xa node contains any non-shadow entry, it can't be reclaimed, shadow_lru_isolate will check and skip such nodes in case of race. > > If so, we may consider some other methods. Make shadow_nodes per-cpu? That's also an alternative solution if there are other risks.