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 85C36C4707B for ; Mon, 15 Jan 2024 01:47:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA1D36B0072; Sun, 14 Jan 2024 20:47:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E507F6B0074; Sun, 14 Jan 2024 20:47:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D18BB6B0075; Sun, 14 Jan 2024 20:47:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BFFFD6B0072 for ; Sun, 14 Jan 2024 20:47:27 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 70C19C0347 for ; Mon, 15 Jan 2024 01:47:26 +0000 (UTC) X-FDA: 81679858092.15.263844D Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) by imf20.hostedemail.com (Postfix) with ESMTP id A5AC91C0006 for ; Mon, 15 Jan 2024 01:47:23 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=KOPbcfwN; spf=pass (imf20.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.11 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=1705283244; 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=WSQjJH62gZWAQ6AS9DHrAQpPP2DySMSTYsrhJn9nhYM=; b=UPBcliZ9VTY3P2OHnsi9/yXQ8jCWOkXgRCxcNSO0XXduJ6t3qx00lMWH44enJrnNu8eghW cZEll9kJCbLn/uyPIH/X8ECJsYJ+b8M9ChWpdITTI2lFjlxwOXbUo3cMxTnf3PiJONuzAc QAfXrRpuwm2uevNPorrthPwFrLmjLaM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705283244; a=rsa-sha256; cv=none; b=p6HG7/2M6uVm+YVY8rJgztm2p93ObrKYt1sZ6cBCVtKQvJDyEiTtmTnLEGYUfbIq5PIjc3 Do64Ap7tRUuMD/kZdPEbohr7XhdpdrH9a8CGgHYj4n72AVdgHD43gHPpz3LTIcrYRjmmp2 NJbfDg9Fe2pGvaQELe9nJhcXJ5EFOQo= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=KOPbcfwN; spf=pass (imf20.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.11 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=1705283244; x=1736819244; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=tosmSLrXCaWa9GRL69WC6iPW9H8RYSG6q69dIiSr7BE=; b=KOPbcfwN4g+hyWVJOAkImBIq55VC6oplX+aryI2QjPV88ol9fQ1JvYO1 9c4u/+DincVbSakgu1oc7HB6Sm40TZD3b/dv06ytiE2L6urBta4k3pF5W 1zOOTGDqbZxebVrIQ5BrrGytkteAZ58z7lN8krsEa6n2EVqtxqLH8x7yT VG+CtVOSv4EWwLArgV+iAEv63ZpPSEtxOvsQ2Cd/7+d3Va6MJx7ChVaqH iuT96JUw6dh295RJ++DGxk7xSh6DEcW7Xy2Q7Gnk0szJvxm+nFzqDDKdH +wYQoq3Cfnb53x8CAPMDuOlBrAKnuRCF7ndaY7FzT6ENiGZbuCekKjwlY w==; X-IronPort-AV: E=McAfee;i="6600,9927,10953"; a="6233085" X-IronPort-AV: E=Sophos;i="6.04,195,1695711600"; d="scan'208";a="6233085" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jan 2024 17:47:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10953"; a="776585349" X-IronPort-AV: E=Sophos;i="6.04,195,1695711600"; d="scan'208";a="776585349" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jan 2024 17:47:17 -0800 From: "Huang, Ying" To: Kairui Song Cc: linux-mm@kvack.org, Andrew Morton , Chris Li , Hugh Dickins , Johannes Weiner , Matthew Wilcox , Michal Hocko , Yosry Ahmed , David Hildenbrand , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 6/9] mm/swap: handle swapcache lookup in swapin_entry In-Reply-To: (Kairui Song's message of "Wed, 10 Jan 2024 10:53:42 +0800") References: <20240102175338.62012-1-ryncsn@gmail.com> <20240102175338.62012-7-ryncsn@gmail.com> <87a5pg9qno.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Mon, 15 Jan 2024 09:45:19 +0800 Message-ID: <87wmsb1ia8.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: sob6rdun9nrg44jttc7ybjai53jxobwy X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: A5AC91C0006 X-Rspam-User: X-HE-Tag: 1705283243-858490 X-HE-Meta: U2FsdGVkX19X1WX8d1FMeCr4ZViVPP8HB5pQ1SBsqwVqlg8aHAhEGwdpGiU23JORxesWd79plF4OBdJvVMoCCPTn4yv+3wGxDmDq5yZ4m6Gbf1n8GqArpRTUwhcphYvfTFO5QVmUdR1jNkf7d329ifiVfeok8dfsFY21SZ+Ml02MFkWy1E1MY66tbojZlGPNQM0ygpXLnHD+OIPBo5VBQu0Nc2y6ZLd1e3aBfJijBF6fq0+bFK0kGYGyWJfxdOqHsX2SnifTTTMmrVfidbRY3St/JoUHUi+f1Jxsf/4moG8T2UjA9freIHKQHNODtf4BH4nUI2t3Z00uRZkL5iGxVuGMJ4yykGeYLb5TTOGu47W2AjDe5nVsdpU6CreKMj86Fs5N1VxFfBFRv0JRFsuuT6aULtcXMG1IoS2VAh+qrnOhRoZxiwUONWZuBqHVguup40nOmkF9JpzJQ/AHJqhgKybjZZmcCkMypLn5yrzgbUD3tAadw8CztNtT5TqW9ucXTxzDNgNWt5fifzjRERLpvYrjXU4dkny64SzR0xAl3DGjbNu+301JOzbkBPlhbAsTavEc1lsXGg1OpP7C8GjUKoOMwflAb33Q1lWcMh0k0xwEKHTj37PsGVQh/EVLqUsh2UcyI5CmUM8MfA0Wta/UhJWDf3eE6A9PztrhJrsUwqvAR+AUFCuuVStJNAALNbnQVhHT4o/MADt3mVtafBqAXFamAUor5mtEwtregB1NBevivy3uNKDYbg72ETLwGbvIH27pwucYkCGJaamVedFLLuD/f03YlCRivv+96cJIKmbKf5jKfW3bCJtQvDU6+ftcXb3WTbDcy/lBYyttFes+Kv3G1XlFyRp27zRiPBqiBf+gRkmMBw/Xkj5VzY5ZvWHx1ESKJiqz4cnf3iaYVGzitpAteiB33ms+LOTW1KAdrwno6CpKtE3raNc9qgcH4dPOXOLd5qh1N/m4JzjWD9A 81DA1tZ/ XpznlkB+S4456yaPx3lh4lDqVhNNHSAYE1XNKs9hsIeVlYTNH2Avkf4/hmmRhPn3gohIjNtwRiACBcWnHZILcMAf54D0JkcohQlBkFKMi9gQPFNFD69GJxl224uovgY3PukxaXa9ifWQIj6v+sLR6dzu4vjvV/XXHmWlPaDc21mUT+W9z/gmkFPArm4J19Ar7yyE6NXs2a/xDvBN3XClVSa/VRqTPgq2FQ6tzVpxJn2AhMJmogfiHpZpJAhDrXmVbxyazm1mC6X44bNO1dBiGNSwP22X5NyHY5AcZvHfhXXDm/D0ftCG3bsjQJJeAnJPFx3X4addMEPkHdYoNv5ukbU4uBGj81nh3vZeL 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: > Huang, Ying =E4=BA=8E2024=E5=B9=B41=E6=9C=888=E6= =97=A5=E5=91=A8=E4=B8=80 16:28=E5=86=99=E9=81=93=EF=BC=9A >> >> Kairui Song writes: >> >> > From: Kairui Song >> > >> > Since all callers of swapin_entry need to check the swap cache first, = we >> > can merge this common routine into swapin_entry, so it can be shared a= nd >> > optimized later. >> > >> > Also introduce a enum to better represent possible swap cache usage, a= nd >> > add some comments about it, make the usage of swap cache easier to >> > understand. >> >> I don't find any benefit to do this. The code line number isn't >> reduced. The concept of swap cache isn't hided either. > > Hi Ying > > Thanks for the comments. > > Maybe I should squash this with the following commit? The following > commit want to do cache lookup in swapin_entry to avoid a redundant > shadow lookup, it can help to improve the performance by about 4% for > swapin path. It's good to improve performance. But I don't think we must put swap_cache_get_folio() in swapin_entry() to do that. We can just get "shadow" from swap_cache_get_folio() and pass it to swapin_entry(). > So it need to return a enum to represent cache status. I don't think we are talking about the same thing here. > Further more, note the comments added here: > > +/* > + * Caller of swapin_entry may need to know the cache lookup result: > + * > + * SWAP_CACHE_HIT: cache hit, cached folio is retured. > + * SWAP_CACHE_MISS: cache miss, folio is allocated, read from swap device > + * and adde to swap cache, but still may return a cached > + * folio if raced (check __read_swap_cache_async). > + * SWAP_CACHE_BYPASS: cache miss, folio is new allocated and read > + * from swap device bypassing the cache. > + */ > > SWAP_CACHE_MISS might be inaccurate, this is not an issue introduced > by this commit, but better exposed. May worth a fix later. So far I > can see two benefits fixing it: > - More accurate maj/min page fault count. > - Note the PageHWPoison check in do_swap_page, it ignored the race > case, if a page getting poisoned is raced with swapcache then it may > not work as expected. > > These are all minor issue indeed, some other optimization might also > be doable, but at least a comment might be helpful. > -- Best Regards, Huang, Ying