linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Yin, Fengwei" <fengwei.yin@intel.com>
To: Yang Shi <shy828301@gmail.com>, Yujie Liu <yujie.liu@intel.com>
Cc: Liam Howlett <liam.howlett@oracle.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"oe-lkp@lists.linux.dev" <oe-lkp@lists.linux.dev>,
	"lkp@intel.com" <lkp@intel.com>,
	Nathan Chancellor <nathan@kernel.org>,
	"Huang, Ying" <ying.huang@intel.com>,
	Rik van Riel <riel@surriel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"feng.tang@intel.com" <feng.tang@intel.com>,
	"zhengjun.xing@linux.intel.com" <zhengjun.xing@linux.intel.com>
Subject: Re: [linus:master] [mm] 0ba09b1733: will-it-scale.per_thread_ops -21.1% regression in mmap1 benchmark
Date: Thu, 22 Dec 2022 09:18:35 +0800	[thread overview]
Message-ID: <ed6c9173-dbbd-6275-a285-04b21de26f13@intel.com> (raw)
In-Reply-To: <CAHbLzkpF4tuuukmhqC1soeVUaS4D5XtDjNDugy9t9D77s_xG8g@mail.gmail.com>



On 12/22/2022 12:45 AM, Yang Shi wrote:
>> We caught two mmap1 regressions on mailine, please see the data below:
>>
>> 830b3c68c1fb1 Linux 6.1                                                              2085 2355 2088
>> 76dcd734eca23 Linux 6.1-rc8                                                          2093 2082 2094 2073 2304 2088
>> 0ba09b1733878 Revert "mm: align larger anonymous mappings on THP boundaries"         2124 2286 2086 2114 2065 2081
>> 23393c6461422 char: tpm: Protect tpm_pm_suspend with locks                           2756 2711 2689 2696 2660 2665
>> b7b275e60bcd5 Linux 6.1-rc7                                                          2670 2656 2720 2691 2667
>> ...
>> 9abf2313adc1c Linux 6.1-rc1                                                          2725 2717 2690 2691 2710
>> 3b0e81a1cdc9a mmap: change zeroing of maple tree in __vma_adjust()                   2736 2781 2748
>> 524e00b36e8c5 mm: remove rb tree.                                                    2747 2744 2747
>> 0c563f1480435 proc: remove VMA rbtree use from nommu
>> d0cf3dd47f0d5 damon: convert __damon_va_three_regions to use the VMA iterator
>> 3499a13168da6 mm/mmap: use maple tree for unmapped_area{_topdown}
>> 7fdbd37da5c6f mm/mmap: use the maple tree for find_vma_prev() instead of the rbtree
>> f39af05949a42 mm: add VMA iterator
>> d4af56c5c7c67 mm: start tracking VMAs with maple tree
>> e15e06a839232 lib/test_maple_tree: add testing for maple tree                        4638 4628 4502
>> 9832fb87834e2 mm/demotion: expose memory tier details via sysfs                      4625 4509 4548
>> 4fe89d07dcc28 Linux 6.0                                                              4385 4205 4348 4228 4504
>>
>>
>> The first regression was between v6.0 and v6.1-rc1. The score dropped
>> from 4600 to 2700, and bisected to the patches switching from rb tree to
>> maple tree. This was reported at
>> https://lore.kernel.org/oe-lkp/202212191714.524e00b3-yujie.liu@intel.com/
>> Thanks for the explanation that it is an expected regression as a trade
>> off to benefit read performance.
>>
>> The second regression was between v6.1-rc7 and v6.1-rc8. The score
>> dropped from 2700 to 2100, and bisected to this "Revert "mm: align larger
>> anonymous mappings on THP boundaries"" commit.
> So it means "mm: align larger anonymous mappings on THP boundaries"
> actually improved the mmap1 benchmark? But it caused regression for
> other usecase, for example, building kernel with clang, which is a
> regression for a real life usecase.
Yes. The patch "mm: align larger anonymous mappings on THP boundaries"
can improve the mmap1 benchmark.

For building kernel regression, looks like it's not related with the
patch "mm: align larger anonymous mappings on THP boundaries" directly.
It's another existing behavior more visible with the patch.
https://lore.kernel.org/all/a4bcddad-e56f-cedc-891a-916e86d9a02c@intel.com/


Regards
Yin, Fengwei

> 


  reply	other threads:[~2022-12-22  1:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-19 11:28 kernel test robot
2022-12-20 18:04 ` Yang Shi
2022-12-20 20:48   ` Liam Howlett
2022-12-21  2:33     ` Yujie Liu
2022-12-21 16:45       ` Yang Shi
2022-12-22  1:18         ` Yin, Fengwei [this message]
2022-12-23  2:45           ` Liam Howlett
2022-12-23  6:27             ` Yin, Fengwei
2022-12-21  2:34   ` Yin, Fengwei

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=ed6c9173-dbbd-6275-a285-04b21de26f13@intel.com \
    --to=fengwei.yin@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=feng.tang@intel.com \
    --cc=liam.howlett@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=nathan@kernel.org \
    --cc=oe-lkp@lists.linux.dev \
    --cc=riel@surriel.com \
    --cc=shy828301@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=ying.huang@intel.com \
    --cc=yujie.liu@intel.com \
    --cc=zhengjun.xing@linux.intel.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