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 61F81C77B72 for ; Thu, 20 Apr 2023 08:39:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C7A22900002; Thu, 20 Apr 2023 04:39:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C2A8B900003; Thu, 20 Apr 2023 04:39:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AFC8E900002; Thu, 20 Apr 2023 04:39:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A1ADE900002 for ; Thu, 20 Apr 2023 04:39:15 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7B7B11601FC for ; Thu, 20 Apr 2023 08:39:15 +0000 (UTC) X-FDA: 80701119870.10.0B11E94 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by imf26.hostedemail.com (Postfix) with ESMTP id 71112140013 for ; Thu, 20 Apr 2023 08:39:12 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=K51pHBV0; spf=pass (imf26.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.31 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=1681979953; 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=gifzRkgVTaCrlnh4tyMThgh1syOXix8mW/LRhqIWiM0=; b=zuJ4yxJNB679BJ/ossOZp7r/9SqbXePkNS2TPsSFXDiCLkkMSgMNzmYxXEUvVVlXrXvp4/ zH6Snpomv4Z6OoWN0tsySxFv5PZHkX/gtT9/FtwdkMoCbpy10DsPXhF4Q/yOxkmXEI3vqT M+39iMipTwHV5WvfFsSvqMaVaycbB7A= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=K51pHBV0; spf=pass (imf26.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681979953; a=rsa-sha256; cv=none; b=Zs+aIbvk13hueP6HPmbtXOyxAVohT5FnZmFQT58TlrzGsHLSMgzBHVTomVBrBlqy2Edo9g cMRhXRXlqyI9PVJDG/faCGSLoM93i7vMRt5F0D9SLJqIUHiD3I776+J4/MqHtqDnsMMd59 o/WY3E0FElGD2ZBBXhDR1a/6QAvuv3I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1681979952; x=1713515952; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=wVsnGwgAugAJ2fpRYz24Pugal7xVqOqt6LioUkpqN9k=; b=K51pHBV0RQXST7IYpF4vWkXEipxvO/rUNC5b3z4DqibR2zwo+6IgTzKK Ksm3pWVk64GHLPB7ioJgplk61CTKlHZOpeVi/d2OvMsO0c1VyGp75T1/V vUl3ZlVFUDY+73/NrjklQ9rF/OwU5zjkMOvzzwF3dMoXXlz1TdKe6Xy2c UplLo8RtSMnXfbmjBEy2F7CIUuDCxp+3SoHiso2d9Z14ahBZjjDmy56mY P0UzCJu6ZeppJ9nLhBrPPNwj7pyJPJ4iSljt30cqTTYRR9Paqd1YQn9z2 rm5PUvctJzWTPFsHa7lerW3xd6oESm+iLmRT+07W0c56kPFZ99AIZVe1h w==; X-IronPort-AV: E=McAfee;i="6600,9927,10685"; a="408587386" X-IronPort-AV: E=Sophos;i="5.99,212,1677571200"; d="scan'208";a="408587386" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2023 01:39:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10685"; a="803270633" X-IronPort-AV: E=Sophos;i="5.99,212,1677571200"; d="scan'208";a="803270633" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2023 01:39:08 -0700 From: "Huang, Ying" To: haoxin Cc: Andrew Morton , , , kernel test robot , Nadav Amit , Mel Gorman , Hugh Dickins , "Matthew Wilcox" , David Hildenbrand Subject: Re: [PATCH] mm,unmap: avoid flushing TLB in batch if PTE is inaccessible References: <20230410075224.827740-1-ying.huang@intel.com> <97e79078-69e8-e387-9e77-a4d741eace4e@linux.alibaba.com> Date: Thu, 20 Apr 2023 16:38:03 +0800 In-Reply-To: <97e79078-69e8-e387-9e77-a4d741eace4e@linux.alibaba.com> (haoxin's message of "Thu, 20 Apr 2023 15:44:03 +0800") Message-ID: <878rent0d0.fsf@yhuang6-desk2.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-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 5wx9g4b48jxdwfscp133yo1cs9e4tinu X-Rspamd-Queue-Id: 71112140013 X-HE-Tag: 1681979952-68924 X-HE-Meta: U2FsdGVkX18Z2uYjRKQGrsyG4UKeBRYuutuXt5L8lRLmDGiH9Qa3gNVStLtUJPjiVka//oWaIpJQ5UeHb+9NQJNO5r8fdM5CJQh2leFdLw+z9r5aRB/Wy074XgMp6NzVWlu/GMxlyaAuzULGDV4XRUpGdgtZjWf6oKnXwHKX2v9cg6GY/OdYU3RTObL66ZwrnL65HcUXDDaqq1BTZjMq6cQ4mZxRc7gzAiXbxCamz8ZcEpIWLJKTYRIkkfveUnb0HcFGf5z1bNVrp5E/anW8uIbKWdqBIicqQ7PdguboiWD+52OPOUHS8ulr74Q+1KVz7402T11oUKDoLYUhntrfT6kAQ/FyOW0bPWpQWRyMltwz5N5nUKUd3G7VynFn8SW+daQIfX22laoWvIM8mf4LYmRVsH+WJHLGF1JDbNxvIyjrqdDpoxWq9ESX5eViKaKM6610BBbKvWRrmkIYnQ0FbKJ7U+ZM6GKWQUeNSHamw2crFywH4VBpBNsbVtrBMZPVSTFC7GRU4PXsMmTjhhn7qCg0abZuUpY6ABah7klNd6M+rerjZyfkY/wyNnX0E9fyMCtfMA15q333uvF96vgtPmk//WN0pe/qoorNoidF4VmVuhabYB7+A5aEYlZuUo/jW4pxurM/6BddGEsCRA8z5PCujiYiUXEiuvEBFd0f2F3Gxy4mGsxpTmCqgJpeBD8npbMwYvnK44XEvo1rGOxowsS/6fVvuYQ8pgT77X9pZP6ZRBOPsXuAUfokD/8UPQ24MXoIXyUciVWHFqdAS4XhL5V9CMvsUHhWBzkpQdtrxYOFCiGDruflFvz1gwQWbg957mMIRgplwDMXGl5KmjATDU5MmA8jqoUt3yzVwugF/Cs+ePMIJpEy/jSQl6edeCspp0+GyLCEQ4GJQUuU+VzpBwxy6fpyp5vzhw1tmJEmiKsKU3qMEw1dyhJcaQJ+d+OVuOYo2a80jMs/35H9ing tPWFL8/a GcD2b2ef1wr+RSJAYPwc2JAGCWHYXs9wipGmunE23vY+yxSSssGtpQlQuOGEH2BDvuyJLm8Gfbv7FMi89/enI0/fM523mSsSsREg9GbNCXcGa058P9LPHrVjk49wyTkXf/52GtESevdBEMxfdhVyHIBGYScnt4UKr79/M0TaEM0FnkP+/KMdJ+f7Jvae8/9TNrw3nBZiXx2HPnv9OxxDZjZLhjEgrt6dkHhyHfoZID/vTrf3BcckCQllrPXxwLSb+8Gg/yzTiZ3WQ3yela+sCdFz1an70Vi52HHmOIT3C3d7kI9nvAB8AaLE3boElH7MgjYJD6cxNMzY+EU97X/2YG2XjGyNfzvSBLrhrS7+kZngxrbvCSDzPOpo3KzbU1097KDJowjitXxdZW/brUum7o9p11zHP1ZUUehNJyDlHqwpvfdoxtzSZAslaxWLzjoPjL/LO18Y6dx8q0Io= 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: haoxin writes: > ( 2023/4/10 H3:52, Huang Ying S: >> 0Day/LKP reported a performance regression for commit >> 7e12beb8ca2a ("migrate_pages: batch flushing TLB"). In the commit, the >> TLB flushing during page migration is batched. So, in >> try_to_migrate_one(), ptep_clear_flush() is replaced with >> set_tlb_ubc_flush_pending(). In further investigation, it is found >> that the TLB flushing can be avoided in ptep_clear_flush() if the PTE >> is inaccessible. In fact, we can optimize in similar way for the >> batched TLB flushing too to improve the performance. >> >> So in this patch, we check pte_accessible() before >> set_tlb_ubc_flush_pending() in try_to_unmap/migrate_one(). Tests show >> that the benchmark score of the anon-cow-rand-mt test case of >> vm-scalability test suite can improve up to 2.1% with the patch on a >> Intel server machine. The TLB flushing IPI can reduce up to 44.3%. >> >> Link: https://lore.kernel.org/oe-lkp/202303192325.ecbaf968-yujie.liu@intel.com >> Link: https://lore.kernel.org/oe-lkp/ab92aaddf1b52ede15e2c608696c36765a2602c1.camel@intel.com/ >> Fixes: 7e12beb8ca2a ("migrate_pages: batch flushing TLB") >> Reported-by: kernel test robot >> Signed-off-by: "Huang, Ying" >> Cc: Nadav Amit >> Cc: Mel Gorman >> Cc: Hugh Dickins >> Cc: Matthew Wilcox (Oracle) >> Cc: David Hildenbrand >> --- >> mm/rmap.c | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/mm/rmap.c b/mm/rmap.c >> index 8632e02661ac..3c7c43642d7c 100644 >> --- a/mm/rmap.c >> +++ b/mm/rmap.c >> @@ -1582,7 +1582,8 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, >> */ >> pteval = ptep_get_and_clear(mm, address, pvmw.pte); >> - set_tlb_ubc_flush_pending(mm, >> pte_dirty(pteval)); >> + if (pte_accessible(mm, pteval)) >> + set_tlb_ubc_flush_pending(mm, pte_dirty(pteval)); >> } else { >> pteval = ptep_clear_flush(vma, address, pvmw.pte); >> } >> @@ -1963,7 +1964,8 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma, >> */ >> pteval = ptep_get_and_clear(mm, address, pvmw.pte); >> - set_tlb_ubc_flush_pending(mm, >> pte_dirty(pteval)); >> + if (pte_accessible(mm, pteval)) >> + set_tlb_ubc_flush_pending(mm, pte_dirty(pteval)); > > Just a advice, can you put pte_accessible() into > set_tlb_ubc_flush_pendin(), just like ptep_clear_flush(); so that we > no need to add if (pte_accessible()) in per place > > where call set_tlb_ubc_flush_pending(); Sounds reasonable for me, will do that in the next version. Thanks for suggestion. Best Regards, Huang, Ying >> } else { >> pteval = ptep_clear_flush(vma, address, pvmw.pte); >> }