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 608D1C54E67 for ; Wed, 27 Mar 2024 06:49:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A171A6B0089; Wed, 27 Mar 2024 02:49:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C7266B0096; Wed, 27 Mar 2024 02:49:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B58D6B0098; Wed, 27 Mar 2024 02:49:47 -0400 (EDT) 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 7B9C86B0089 for ; Wed, 27 Mar 2024 02:49:47 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 37F4680A5B for ; Wed, 27 Mar 2024 06:49:47 +0000 (UTC) X-FDA: 81941893614.06.B55B5E9 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) by imf02.hostedemail.com (Postfix) with ESMTP id 2C6918000B for ; Wed, 27 Mar 2024 06:49:43 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="Rq7/aPb6"; spf=pass (imf02.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.19 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711522185; 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=X2RCSLf7ypV2Z1in03ulc0Gi7o9Tn/EfpLBlwrrDqSk=; b=5fTxiVCLip3U8RP8mlBqse1Yeq0TdRq0d+st3ctYCONdOL3w4hVcXcfSIq/+wefn5VaFHG ON+x8eHjjksuygVk3O74HLaHVA1vavvkKG0luHwpor/7tsHBI93M9QLbAZ52O9RcPKM6In 1vzTHtLITdSmW0TP8HDr/G2XYmu9d7M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711522185; a=rsa-sha256; cv=none; b=d9hfa/+0Dlj86pSaLvJC3nmioFxEVwo924HI3KaZhuVo+zzb2DU8NgdswYY3bk2ECHEMeS 0+43q2CrSSSyW6WfXiH6Rf0D+sE4YAR61ndZy6u5t3Cw++hOxbuIL7Cxf+SC95qSw8hcMf MluWsNr370hn33SInKQ3Fhymjexbqko= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="Rq7/aPb6"; spf=pass (imf02.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.19 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1711522184; x=1743058184; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=NpBdR2o53eZcSNfBWFivW7bvko295qnK4Dgh0nt/fNc=; b=Rq7/aPb6krT9tG+sjees82J+iJ/TMaESqQ3WP+TgJBtB8yyGJhIhIlG3 mxk0nzlvf39rNcArM8RuzJVK9ySRlf40zgHjJMIndGwlLEbixvG9Y4QJu 3ga3ZfnDw7rvaY2POypmcfkMcsqbMP95G6FUUFHRcnU3lqTCDRrrSftWx AWEZ108rb5TseT10Oa2rZuzLHnz+4vxnhpRPuXrg+B0jDgVF1z2kwZ3S5 1Ey936DRtN3MLflygnzaBKa6EIIHL2ngD9n6ss0c8gZAjouTxRieqzadP yNPbtRCd3Q3sde5FAqaz73iUDFAG4SJeiV2YOA7gC9Z6xvIm2wFYS4fvC A==; X-CSE-ConnectionGUID: S3W+6CSSS4u9FGGPVoZixA== X-CSE-MsgGUID: wrPuEEG7RfKNIYxmU2ni+g== X-IronPort-AV: E=McAfee;i="6600,9927,11025"; a="6462092" X-IronPort-AV: E=Sophos;i="6.07,158,1708416000"; d="scan'208";a="6462092" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2024 23:49:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,158,1708416000"; d="scan'208";a="16185085" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2024 23:49:37 -0700 From: "Huang, Ying" To: Kairui Song 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 Subject: Re: [RFC PATCH 10/10] mm/swap: optimize synchronous swapin In-Reply-To: (Kairui Song's message of "Wed, 27 Mar 2024 14:37:27 +0800") References: <20240326185032.72159-1-ryncsn@gmail.com> <20240326185032.72159-11-ryncsn@gmail.com> <87zfukmbwz.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Wed, 27 Mar 2024 14:47:43 +0800 Message-ID: <87r0fwmar4.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Stat-Signature: t9ejekfo7dnt3xrrd839ztpt86bua6we X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 2C6918000B X-Rspam-User: X-HE-Tag: 1711522183-829790 X-HE-Meta: U2FsdGVkX1+fd/12GR7hNiKtmPrzbTSGN92L6WNv4lGoKLXTUwzGf+NRoSqbKABbPeO58+3itIEVDRVj6WWQeS6oE9YekzAU1dpqujx8ZfTJ9+QVxefE4jQonau6O6k/v5dsRS24T1/doePPHOJ/Yy4rWhiMQH5FJ1Dam+671cFlf8fauLa5EiwUFlJ1ELBfV0OTHypQ9DE4sSyHUF2trpLFElYw34qBpUC7nELWEGMy7mIhr9RgqlGZM8/wyOZqdbmnkcQWG9rc0UsEhdX774itCU8blkkUiWi0uknC49hZsga7RewdpZJpOPlnhRIM9zGQOzMRby/KfcwMfaHpP7dhhPtRJdQS5yQC0ppCvsaib8kdaKxbBHenoe2mocxEf+3g7Ki6qMT+WVe2ChpLb0z8T3UWRV2+yQRMZNLA2SXSmvMt5EVmQpDnGUUvNMXqGTqFMonTdyGrypchVEatVyDeL3r9n718KM5L54QhKcuaZLF1A2ETclaTyWWvnjgoYADXuJiKFgpMeynzSZgDMgkEz4rdK3l+0aXMfBQO7zoNmwfPYUvHasqhAbFqALq1geogBInpJwKIDT7YpTSaSY/coHQjmxCCC5WUA1Gdqwm3MlojUtk4x9rihlCUkFJ/YJuxZnrcn5QjKUghE1q+A+wB/CS4ZlQTcbeZe41kblZacI1bH5Qd7RIcS+BDdkEDGiDDTkPbqXJWuxPeJplO1SRsjQ1WOaG4d8sJrGpZ9HRRvIn6z82t31KNfL2O9eliqvXIy9/7dU5yXy0UATXnJw61yn598QHEKB54apwlP50NO3uW2LDc67fpSL7gsNaCA+clCDHg4zLjGaBnctJoUFyWOHFV/8Etpf/fM5IXLc2bTcIP49mOjotZ+P2oQBcRwWivdsK8aTZ0K15bC74SrnP5zJZjjY0FH/mJRLM7Iidn2r6/6WIrPGV1Vpt3IoCE7b95H0HIrZ+QvD47p0+ D7QBAQv/ 3m3nS8i+2c7mOayaQjo95vP1XWF1PjOrnspvFs/zBLlmzaSGfZgKKFQ5uAjUygymr8ia/BGtLy+LeG4qQlZHODgqKb1EbId/RqMp2CahfS4KGLq+AH5adFZ5fq+HMIXcQnqIaYG6VgiXcVI7kgIHZMOTklPmIosCDWzFpElnqKmDefBaxh7PjBo+Hn0f1tQq6COP7mOkZ2SXIAK8uYIJsE5+7XWFKy1u8Fy5m/j+1NTs8l8zmeENxUh/OQHwiosyY42g/etC0o3AtcLExVeUYJjhBWg== 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: Kairui Song writes: > 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 workings= et >> > 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. In shadow_lru_isolate(), /* * The nodes should only contain one or more shadow entries, * no pages, so we expect to be able to remove them all and * delete and free the empty node afterwards. */ if (WARN_ON_ONCE(!node->nr_values)) goto out_invalid; if (WARN_ON_ONCE(node->count !=3D node->nr_values)) goto out_invalid; So, this isn't considered normal and will cause warning now. >> >> If so, we may consider some other methods. Make shadow_nodes per-cpu? > > That's also an alternative solution if there are other risks. This appears a general optimization and more clean. -- Best Regards, Huang, Ying