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 148CDCCF9EB for ; Thu, 26 Sep 2024 02:03:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 56A728D0003; Wed, 25 Sep 2024 22:03:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 519848D0002; Wed, 25 Sep 2024 22:03:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 36C128D0003; Wed, 25 Sep 2024 22:03:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 1444D8D0002 for ; Wed, 25 Sep 2024 22:03:35 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B7C4D1C7004 for ; Thu, 26 Sep 2024 02:03:34 +0000 (UTC) X-FDA: 82605242748.04.4DC9683 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) by imf05.hostedemail.com (Postfix) with ESMTP id EDCFC100005 for ; Thu, 26 Sep 2024 02:03:31 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=harD6vKz; spf=pass (imf05.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.18 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=1727316093; 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=apwHKQarc7jbd/r9Xf/Kr1Paa78DHyhho5S7ei4aaCc=; b=fZAN9zpjNiwhM7X+hycmYxTfHv7vgvovnlP08DbVw7d0hDjB5MZN5Z6i5jC16clwUf5Eb5 o3yAjnqIZDMrY1suYoJZbSAzUe9kAfvoor4MdQqbszt3cBKNEF6LwBzHtoIpZJn5AW1H4q rmSu5jbivGAjEGvEV5ASQbW8QcKYpcg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727316093; a=rsa-sha256; cv=none; b=Pr4V/DC9cA6R9QqPtY06PhSKyODFhwYh4RlyfGVnpKzNaN/cDl53aq4cH968TB1bvQgpfr HS/AulUjU8jf9K7qJKBJ2Q2f/NGb4ZF1W6wwzKDuDAtH5l4cG+3b3axNEWRyxxpqN5JdXE iHn557RRMcgQVRReh1I6tjZx7i6nnXg= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=harD6vKz; spf=pass (imf05.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.18 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=1727316212; x=1758852212; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=Sl3F7flDuPPcQnO2qXWYfmucaK/BNWTk+/YHVoRe8HI=; b=harD6vKzhNotWWZtakHF4wYYhc1BA3GNNzKeurZJcCL+Y3YjsI1Iq6kW eUGe8Rs1ugNh9yFJK//KL6Veqn8Hw5XDM/sg3Lt9mN9a2+qSuHQ9QTnJy rWQKv2reRJ+lMIGtHY5BhOTcH1F0lzWRYEwKt5CyRzLFUNyv1MrLPwGvl DFN3xRbMjWczUTS8zCrazqSsUFaoDnrFPaIfDppx5FvEpedlTJNd2t0C4 QRGGmaChgdxXPtaaAENVbCZGfrRgFFeMTfcVQI7bzwONSgBz/LQX/05xB Mvg9xEpx+hMllKMPbVDBXHhc482NKyBkVN07Ypf4Q2/kqCf4AvVHsv+Ll Q==; X-CSE-ConnectionGUID: wCaJXuf9R9m9kqRg/IAQ3g== X-CSE-MsgGUID: WvOqdepOQ/ezF6Mgajmmjw== X-IronPort-AV: E=McAfee;i="6700,10204,11206"; a="25866990" X-IronPort-AV: E=Sophos;i="6.10,259,1719903600"; d="scan'208";a="25866990" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Sep 2024 19:03:30 -0700 X-CSE-ConnectionGUID: aGaQrNntTPy3jbEWuHGjBQ== X-CSE-MsgGUID: VSRods/SToqX4Q1s4Wtrfw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,259,1719903600"; d="scan'208";a="72071831" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Sep 2024 19:03:26 -0700 From: "Huang, Ying" To: Nhat Pham Cc: Baolin Wang , Yosry Ahmed , akpm@linux-foundation.org, hannes@cmpxchg.org, hughd@google.com, shakeel.butt@linux.dev, ryan.roberts@arm.com, chrisl@kernel.org, david@redhat.com, kasong@tencent.com, willy@infradead.org, viro@zeniv.linux.org.uk, baohua@kernel.org, chengming.zhou@linux.dev, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/2] remove SWAP_MAP_SHMEM In-Reply-To: (Nhat Pham's message of "Wed, 25 Sep 2024 07:37:12 -0700") References: <20240923231142.4155415-1-nphamcs@gmail.com> <4d38c65d-760c-43a5-bb47-8e0235c13a51@linux.alibaba.com> <9a110f20-42ad-468b-96c6-683e162452a9@linux.alibaba.com> <85a2fd61-93d3-4cd9-95a3-e9eaef87286b@linux.alibaba.com> Date: Thu, 26 Sep 2024 09:59:53 +0800 Message-ID: <87y13fqina.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-Rspamd-Queue-Id: EDCFC100005 X-Stat-Signature: mwcy387hebg16ssxaimxn7noew8y63o1 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1727316211-457456 X-HE-Meta: U2FsdGVkX18fJTFf7HlFH3NjCHx3gXg8ZaOcvXJsM4dYOwIKOEoUDqLvcUxnPfUZvbGfAzi0mOTXhPudIaZAF9Yzj2ycwa5MbkYT9ppxww07ury95NU+ibmoGtZB3bYld3DfCo2Cg7/8oQ/pGBRwdyRZQhL/GfkJYZh+xe/QUu8w5NPyenHU2Qk83wuV18gcbPUIlGHYt49sWMF0SwljVGzdcQJPBda9VjkwSqmKhykQH88V/Cd5lFDXTHwlxqZj/xooHJHBR5aSdO/ZpzKPP55nk6OQ3d7tvrvu19j9LnQrIkAJFix9cnx62EpF5qieArLYKE+tllif/MVNQP21lNjAgeLe2pjP/NOU8Gfn7J0kuiXN/wXEZgUHo5iQOLgqg68j2Aw6VrgNET+WgAVqvW0IIvGG8zS3L9zBy5+NHplhklLPdYaBnzFBlVxUwG7AsE2/GRMvuEExiGk3LF8MJa9PteIpLJdgHvxnhgPl9dZy6VslkT2U1gVSCzDm9RNBauHN3gz1Af+2bBOBE5Bvyu+XC76f6p/+D3vpjrJcNsBcWA3Ax8B18zO01fJvRbvXEfoVa/andAdxcqLqfVcydXMPEcmIr1dZ8+h7ychf9uibdzg9pGlSQ6FCUv2Fm4MLn+B/t16ZTgzPwDXct+LPDI7zu2kCzb0biNAFJqVCiWc0TbtyI0ywx0pMcH9qzwEHGH/EN3O7iLelh4SDJKCByONa3D3m5N4o+J52edG4pBUVOjbZ7EfL0e6uiLEGOkOX7KLNZwcoIlh5Ec7GveTkHNxBGnWtGKTGvgT1OwCWWLMdkVTumZ+rL6eGgYiQF5fnKtKEOcuv2h5KQuvkSy/KiNWsACYnVL2n7U0ryS8EuIPVBzJTr2HKaVUjTqIEAO+IptzYV9IVOCb1gW0orbrjTBz400nxgRnUUNI8Umw64FY8nGJAEQIYEAQSUsRjPVo5+Wcw4UZGVlFApB6YnaV pTz0aV7J GDEcpwb4r1kKgO/A0OjhVpghkJ9AeIXbKDIn5U/J8lpaTcB0P8/w46MYWiI1qVIWRWnvcBJfwo/3sEMgL18KQcTMRHdGhc72O2oBd2KXnQUZVBSPD6pjGbRAgdOTeMiv6GBedfK9xKCASf2yJysFQd3DWmoPpqAhiOQHnk3R6eLXDIin5ngMKE/DAoierhkuluspws7VysTHMfVy9pM+YhpMYcYADL/9AI5rvScLCoTP2NGMo2t+3b7nOAZyajyYEz4/vpS066ShhO+M= 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: Nhat Pham writes: > On Tue, Sep 24, 2024 at 6:53=E2=80=AFPM Baolin Wang > wrote: >> >> >> One benefit I can mention is that removing 'SWAP_MAP_SHMEM' can help to >> batch free shmem swap entries in __swap_entries_free(), similar to the >> commit bea67dcc5eea ("mm: attempt to batch free swap entries for >> zap_pte_range()") did, which can improve the performance of shmem mTHP >> munmap() function based on my testing. > > Yeah, the problem with having an extraneous state is you have to > constantly check for it in code, and/or keep it in mind when you > develop things. I've been constantly having to check for this state > when I develop code around this area, and it gets old fast. > > If we can use it to optimize something, I can understand keeping it. > But it just seems like dead code to me :) > > My preference is to do this as simply as possible - add another case > (usage =3D=3D 1, nr > 1, and we need to add swap continuations) in the > check in __swap_duplicate()'s first loop, and just WARN right there. > > That case CANNOT happen UNLESS we introduce a bug, or have a new use > case. When we actually have a use case, we can always introduce > handling/fallback logic for that case. > > Barry, Yosry, Baolin, Ying, how do you feel about this? Sounds good to me to just WARN now. We can always improve when it's necessary. -- Best Regards, Huang, Ying