From: "Huang, Ying" <ying.huang@intel.com>
To: kernel test robot <yujie.liu@intel.com>
Cc: <oe-lkp@lists.linux.dev>, <lkp@intel.com>,
<linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Xin Hao <xhao@linux.alibaba.com>, Zi Yan <ziy@nvidia.com>,
Yang Shi <shy828301@gmail.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Oscar Salvador <osalvador@suse.de>,
"Matthew Wilcox" <willy@infradead.org>,
Bharata B Rao <bharata@amd.com>,
"Alistair Popple" <apopple@nvidia.com>,
Minchan Kim <minchan@kernel.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>, <linux-mm@kvack.org>,
<feng.tang@intel.com>, <zhengjun.xing@linux.intel.com>,
<fengwei.yin@intel.com>
Subject: Re: [linus:master] [migrate_pages] 7e12beb8ca: vm-scalability.throughput -3.4% regression
Date: Mon, 20 Mar 2023 15:58:42 +0800 [thread overview]
Message-ID: <87o7onua4t.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <202303192325.ecbaf968-yujie.liu@intel.com> (kernel test robot's message of "Mon, 20 Mar 2023 09:12:16 +0800")
Hi, Yujie,
kernel test robot <yujie.liu@intel.com> writes:
> Hello,
>
> FYI, we noticed a -3.4% regression of vm-scalability.throughput due to commit:
>
> commit: 7e12beb8ca2ac98b2ec42e0ea4b76cdc93b58654 ("migrate_pages: batch flushing TLB")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> in testcase: vm-scalability
> on test machine: 96 threads 2 sockets Intel(R) Xeon(R) Platinum 8260L CPU @ 2.40GHz (Cascade Lake) with 128G memory
> with following parameters:
>
> runtime: 300s
> size: 512G
> test: anon-cow-rand-mt
> cpufreq_governor: performance
>
> test-description: The motivation behind this suite is to exercise functions and regions of the mm/ of the Linux kernel which are of interest to us.
> test-url: https://git.kernel.org/cgit/linux/kernel/git/wfg/vm-scalability.git/
>
>
> If you fix the issue, kindly add following tag
> | Reported-by: kernel test robot <yujie.liu@intel.com>
> | Link: https://lore.kernel.org/oe-lkp/202303192325.ecbaf968-yujie.liu@intel.com
>
Thanks a lot for report! Can you try whether the debug patch as
below can restore the regression?
Best Regards,
Huang, Ying
-------------------------------------8<------------------------------------
From 1ac61967b54bbdc1ca20af16f9dfb2507a4d4811 Mon Sep 17 00:00:00 2001
From: Huang Ying <ying.huang@intel.com>
Date: Mon, 20 Mar 2023 15:48:39 +0800
Subject: [PATCH] dbg, rmap: avoid flushing TLB in batch if PTE is inaccessible
Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
---
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));
} else {
pteval = ptep_clear_flush(vma, address, pvmw.pte);
}
--
2.30.2
next prev parent reply other threads:[~2023-03-20 8:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-20 1:12 kernel test robot
2023-03-20 7:58 ` Huang, Ying [this message]
2023-03-21 3:24 ` Liu, Yujie
2023-03-21 5:43 ` Huang, Ying
2023-03-22 5:17 ` Liu, Yujie
2023-03-23 1:53 ` Huang, Ying
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o7onua4t.fsf@yhuang6-desk2.ccr.corp.intel.com \
--to=ying.huang@intel.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=bharata@amd.com \
--cc=feng.tang@intel.com \
--cc=fengwei.yin@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=mike.kravetz@oracle.com \
--cc=minchan@kernel.org \
--cc=oe-lkp@lists.linux.dev \
--cc=osalvador@suse.de \
--cc=shy828301@gmail.com \
--cc=willy@infradead.org \
--cc=xhao@linux.alibaba.com \
--cc=yujie.liu@intel.com \
--cc=zhengjun.xing@linux.intel.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox