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 855F4C47DD9 for ; Thu, 28 Mar 2024 01:11:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D2D26B0083; Wed, 27 Mar 2024 21:11:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 083186B0085; Wed, 27 Mar 2024 21:11:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8C636B0087; Wed, 27 Mar 2024 21:11:46 -0400 (EDT) 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 CBBF66B0083 for ; Wed, 27 Mar 2024 21:11:46 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 64AD780B90 for ; Thu, 28 Mar 2024 01:11:46 +0000 (UTC) X-FDA: 81944670612.20.9481A53 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) by imf15.hostedemail.com (Postfix) with ESMTP id 3E4DCA0005 for ; Thu, 28 Mar 2024 01:11:44 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ZTvXeYiL; spf=pass (imf15.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.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=1711588304; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pvPZ3gCpspX9z+OhbECCd94yUAn2v27iuPWH4oyiNFY=; b=jC8hU9pCgPScG8swY7mBGUoryL1pVGv5Y+Btgn8jEvIKG748Azn2WlT2EJ6gcYcrkTS1P/ Flik6oHlt8PHaoTew+8ZIdh7KaQjDku1fIQy/ESFlDR0AdzsnwPz1WPkx85DeOznvnmbup t86oY0ni1oIR3F1HP5pI0JxlDL+CySs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711588304; a=rsa-sha256; cv=none; b=d4ufBkRNgJhhOcMK/jF4aGKaIZrQHUDpVrbLsJlPpV8yWhBoBrWLycoXy2n+tUYz0yOUZr SroC6kW8tOsMuY60pIIVXJbGDHXP2TEiBCbItpDAjRURsRPku/xEFW8YAAmO003WuLERn5 230jMB1Kgc1Ja0do6JLXKzDWNXdIxV0= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ZTvXeYiL; spf=pass (imf15.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.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=1711588304; x=1743124304; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=Jry9g/dJ8ZW6iFxkM5spwjAOPWz0jtQCXuPGBGOxKBg=; b=ZTvXeYiL8Mx4kk+HYQq3nGY8rjyyoZe4fy9gsKJW8guKGI0hdhAhDmj+ HNgAViRqadOjSnymD9VcC2iTlZ/42cA2oUQBTW9Q/ERCE7bin4IVIvb1Z Bl+kccZn2zBx17duJ1ICsuYEyCWQd+l7kBeEqSXoCtsTo+N09OvYsHXSi Cita8huxnHwp7OSk6jsiZ/+6Odefg/Qozgy+UiK+mlignJObVTY9ZYrg+ JImc+5hz6HQBdCJ/m1FQKjwcBw7aIjy7vv4zr4ElT4ys7bRFwt1YCq97S Ojd4/IqBZmN64R+Mc7rIWOfc8HVXbbSDhGagTkETiG9Edc1/QMy3qRHkq A==; X-CSE-ConnectionGUID: 4njn6/mTRHKm+wNrI3hVbw== X-CSE-MsgGUID: UggCzWX8TjCQ1/v0pkXmtw== X-IronPort-AV: E=McAfee;i="6600,9927,11026"; a="6584741" X-IronPort-AV: E=Sophos;i="6.07,160,1708416000"; d="scan'208";a="6584741" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Mar 2024 18:11:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,160,1708416000"; d="scan'208";a="16878153" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Mar 2024 18:11:40 -0700 From: "Huang, Ying" To: David Hildenbrand Cc: Baolin Wang , akpm@linux-foundation.org, mgorman@techsingularity.net, wangkefeng.wang@huawei.com, jhubbard@nvidia.com, 21cnbao@gmail.com, ryan.roberts@arm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] mm: support multi-size THP numa balancing In-Reply-To: <6248d6fb-b982-4ebd-93a9-7750cc4a5039@redhat.com> (David Hildenbrand's message of "Wed, 27 Mar 2024 09:47:24 +0100") References: <87cyrgo2ez.fsf@yhuang6-desk2.ccr.corp.intel.com> <87edbwm6fh.fsf@yhuang6-desk2.ccr.corp.intel.com> <6248d6fb-b982-4ebd-93a9-7750cc4a5039@redhat.com> Date: Thu, 28 Mar 2024 09:09:46 +0800 Message-ID: <8734sbmaat.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Stat-Signature: e4x8i51bojejtim5xaozhm7o41wfkgb4 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 3E4DCA0005 X-Rspam-User: X-HE-Tag: 1711588304-815114 X-HE-Meta: U2FsdGVkX1+zoyaEuyzDY3GUOjDIoB/dclsgS4Jyf8qaLVwE33tK0y8JIaUwu3gJ2oLuDpGo0gjSiNXJd/lx+wVLm2b9lQIZ739hoPm/Eik5GNG9k3Y0gyi6vXFP5cpWBuxrNp1An5OiL4m9sGoGEK/Xi7IwTaTOgdh7TDiE3vgeMbkgJlsen2+UTVgfJIoCBg5kqvif3q5eRs35zf8/YSz1PcvsCSwMJqa1ycU8zNxa/H7q2ixVmNzs13W8V92jVYtl6TR0b7BpoqFgfhKjsLZhD3iWQr4vo7ZR+mPXbI2gCGRXAsavPgr2Ly76lGWCKiJ1aDRxN1pMeASSxyYvJmUaqEd16OgtjNMrLGicBsxiO0Mi+inYAW/ezB8JbuNFgWEFxSbD+xIlrZHgWqQvmrs7DELBOy9rxAyySAgwvozWI/KmOcuYITxsqfF/iqzAPr8PEP0dXVfdk5Jz9opYm6/bCG3syIQOJqb+AES2wOVL1esVopCFl8MoShHUqPugDxPSUctfLb9KYir2aTM71ilXWgySyEdvjGIk94OWDJd316kW/2saXqPoVdg+8ApKlRCp4UNhjqTCBXY+HuXm2y4wcnsvsz6gDeqnAilpCi8kO6YbY6O8Uo/6TBo0TE/IrHlO2+9O0W74QZcxDHVeiC8F7WFXVnNcfN1zueyRxTmfWcG5+VL6sDxiTbkLDme/aaM1IaP10+JRIztDaYGhnSJl/+JK3bEp5yusU1mdaXZmYDwbP2wG8heGqnSF/VS+3ZYnI3Gc5dNhKJiB6wzl/yR40d14fjh5CVKcBl6yndXBOVHmdju/y+T1iFyp6lT9Ttwcn3jcgnj26At56ANrf7a2jEhRTUTuTH4EcTlrojUKB781YtlEZ3FL2sz0tpntwKsOSeSLQ/dQockTwDe4uNZn7uAZ6Wmo7jLxBtW/+d9g7SEmNJ1ZLnSWqV5QiS18M14LZRmo5mefr+CAbVW NpsWXDJT dIiWksr9YNoViml0ZHmRnW1gEhemcvAYTRt9FuCZgBb9WJMBepX55XDuNlf4xHTA1nsLXIGugnb+wALy+watHZztg6lUHgKkVmz8UCFugqSLUf23j3PlhKEjINMqiBwk2OZe4OkGlYe6swRoY8SIoeyXUh5MryAKFjsT2iMAThi0VoCxByokz0O/BSAly0Q+t2bAB0ZeB+HEyTGehD282jZJASQ== 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: David Hildenbrand writes: > On 27.03.24 09:21, Huang, Ying wrote: >> Baolin Wang writes: >> >>> On 2024/3/27 10:04, Huang, Ying wrote: >>>> Baolin Wang writes: >>>> >>>>> Now the anonymous page allocation already supports multi-size THP (mTHP), >>>>> but the numa balancing still prohibits mTHP migration even though it is an >>>>> exclusive mapping, which is unreasonable. >>>>> >>>>> Allow scanning mTHP: >>>>> Commit 859d4adc3415 ("mm: numa: do not trap faults on shared data section >>>>> pages") skips shared CoW pages' NUMA page migration to avoid shared data >>>>> segment migration. In addition, commit 80d47f5de5e3 ("mm: don't try to >>>>> NUMA-migrate COW pages that have other uses") change to use page_count() >>>>> to avoid GUP pages migration, that will also skip the mTHP numa scaning. >>>>> Theoretically, we can use folio_maybe_dma_pinned() to detect the GUP >>>>> issue, although there is still a GUP race, the issue seems to have been >>>>> resolved by commit 80d47f5de5e3. Meanwhile, use the folio_likely_mapped_shared() >>>>> to skip shared CoW pages though this is not a precise sharers count. To >>>>> check if the folio is shared, ideally we want to make sure every page is >>>>> mapped to the same process, but doing that seems expensive and using >>>>> the estimated mapcount seems can work when running autonuma benchmark. >>>> Because now we can deal with shared mTHP, it appears even possible >>>> to >>>> remove folio_likely_mapped_shared() check? >>> >>> IMO, the issue solved by commit 859d4adc3415 is about shared CoW >>> mapping, and I prefer to measure it in another patch:) >> I mean we can deal with shared mTHP (by multiple threads or multiple >> processes) with this patch. Right? > > It's independent of the folio order. We don't want to mess with shared COW pages, see > > commit 859d4adc3415a64ccb8b0c50dc4e3a888dcb5805 > Author: Henry Willard > Date: Wed Jan 31 16:21:07 2018 -0800 > > mm: numa: do not trap faults on shared data section pages. > Workloads consisting of a large number of processes running > the same > program with a very large shared data segment may experience performance > problems when numa balancing attempts to migrate the shared cow pages. > This manifests itself with many processes or tasks in > TASK_UNINTERRUPTIBLE state waiting for the shared pages to be migrated. > ... > > that introduced this handling. Sorry, I misunderstood your words. -- Best Regards, Huang, Ying