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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A1AFC433B4 for ; Thu, 15 Apr 2021 06:46:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AFAA86113D for ; Thu, 15 Apr 2021 06:46:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AFAA86113D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CAAFF6B0036; Thu, 15 Apr 2021 02:46:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C59996B006C; Thu, 15 Apr 2021 02:46:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B214A6B0070; Thu, 15 Apr 2021 02:46:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0202.hostedemail.com [216.40.44.202]) by kanga.kvack.org (Postfix) with ESMTP id 994AE6B0036 for ; Thu, 15 Apr 2021 02:46:08 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3FDCE2816 for ; Thu, 15 Apr 2021 06:46:08 +0000 (UTC) X-FDA: 78033666816.12.9480F77 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf24.hostedemail.com (Postfix) with ESMTP id 02B94A0003A3 for ; Thu, 15 Apr 2021 06:46:00 +0000 (UTC) IronPort-SDR: S6qR7tIXQk43AiqoNSJDTffIEjYb/J9JP2OqdwTECeL4ZPBXyRxd6dbygTblKn+6jUevnkttvg blPlp2IA/AcA== X-IronPort-AV: E=McAfee;i="6200,9189,9954"; a="194822092" X-IronPort-AV: E=Sophos;i="5.82,223,1613462400"; d="scan'208";a="194822092" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2021 23:46:02 -0700 IronPort-SDR: 1pfPbXhjlYYReGkPxq6HfP4+S3mzqWZg9G55ESeGOM9vhqkGCJ7BYRc35RiXXmWynnugSAJ6uM atnC5MlIfazg== X-IronPort-AV: E=Sophos;i="5.82,223,1613462400"; d="scan'208";a="425061751" Received: from yhuang6-desk1.sh.intel.com (HELO yhuang6-desk1.ccr.corp.intel.com) ([10.239.13.1]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2021 23:45:58 -0700 From: "Huang, Ying" To: "Zi Yan" Cc: Yang Shi , , , , , , , , , , , , Subject: Re: [v2 PATCH 6/7] mm: migrate: check mapcount for THP instead of ref count References: <20210413212416.3273-1-shy828301@gmail.com> <20210413212416.3273-7-shy828301@gmail.com> <87k0p5sh7h.fsf@yhuang6-desk1.ccr.corp.intel.com> <6297AD92-8D0E-4BEC-8E1F-5C5AC32FA128@nvidia.com> Date: Thu, 15 Apr 2021 14:45:54 +0800 In-Reply-To: <6297AD92-8D0E-4BEC-8E1F-5C5AC32FA128@nvidia.com> (Zi Yan's message of "Wed, 14 Apr 2021 11:02:58 -0400") Message-ID: <87fszsoxjx.fsf@yhuang6-desk1.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Stat-Signature: fitn7dj93a775hmj4dxwrfagxi5u18e7 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 02B94A0003A3 Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf24; identity=mailfrom; envelope-from=""; helo=mga03.intel.com; client-ip=134.134.136.65 X-HE-DKIM-Result: none/none X-HE-Tag: 1618469160-483458 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000075, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: "Zi Yan" writes: > On 13 Apr 2021, at 23:00, Huang, Ying wrote: > >> Yang Shi writes: >> >>> The generic migration path will check refcount, so no need check refcount here. >>> But the old code actually prevents from migrating shared THP (mapped by multiple >>> processes), so bail out early if mapcount is > 1 to keep the behavior. >> >> What prevents us from migrating shared THP? If no, why not just remove >> the old refcount checking? > > If two or more processes are in different NUMA nodes, a THP shared by them can be > migrated back and forth between NUMA nodes, which is quite costly. Unless we have > a better way of figuring out a good location for such pages to reduce the number > of migration, it might be better not to move them, right? > Some mechanism has been provided in should_numa_migrate_memory() to identify the shared pages from the private pages. Do you find it doesn't work well in some situations? The multiple threads in one process which run on different NUMA nodes may share pages too. So it isn't a good solution to exclude pages shared by multiple processes. Best Regards, Huang, Ying