mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Xing Zhengjun <zhengjun.xing@linux.intel.com>
To: Mike Kravetz <mike.kravetz@oracle.com>,
	kernel test robot <rong.a.chen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@kernel.org>, Hugh Dickins <hughd@google.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	"Kirill A.Shutemov" <kirill.shutemov@linux.intel.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Prakash Sangappa <prakash.sangappa@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@lists.01.org
Subject: Re: [LKP] Re: [hugetlbfs] c0d0381ade: vm-scalability.throughput -33.4% regression
Date: Mon, 12 Oct 2020 13:29:13 +0800	[thread overview]
Message-ID: <68992a81-a1b9-467b-59c4-48ab65c601c5@linux.intel.com> (raw)
In-Reply-To: <1f6d321e-96b4-18c3-2991-d6a2e94c9e60@oracle.com>

Hi Mike,

    I re-test it in v5.9-rc8, the regression still existed. It is almost 
the same as 34ae204f1851. Do you have time to look at it? Thanks.

=========================================================================================
tbox_group/testcase/rootfs/kconfig/compiler/runtime/size/test/cpufreq_governor/ucode:
 
lkp-knm01/vm-scalability/debian-x86_64-20191114.cgz/x86_64-rhel-7.6/gcc-7/300s/8T/anon-cow-seq-hugetlb/performance/0x11

commit:
   49aef7175cc6eb703a9280a7b830e675fe8f2704
   c0d0381ade79885c04a04c303284b040616b116e
   v5.8
   34ae204f18519f0920bd50a644abd6fefc8dbfcf
   v5.9-rc1
   v5.9-rc8

49aef7175cc6eb70 c0d0381ade79885c04a04c30328                        v5.8 
34ae204f18519f0920bd50a644a                    v5.9-rc1 
   v5.9-rc8
---------------- --------------------------- --------------------------- 
--------------------------- --------------------------- 
---------------------------
          %stddev     %change         %stddev     %change 
%stddev     %change         %stddev     %change         %stddev 
%change         %stddev
              \          |                \          |                \ 
         |                \          |                \          | 
          \
      38043 ±  3%     -30.2%      26560 ±  4%     -29.5%      26815 ± 
6%      -7.4%      35209 ±  2%      -7.4%      35244            -8.8% 
   34704        vm-scalability.median
       7.86 ± 19%      +9.7       17.54 ± 21%     +10.4       18.23 ± 
34%      -3.1        4.75 ±  7%      -4.5        3.36 ±  7%      -4.0 
     3.82 ± 15%  vm-scalability.median_stddev%
   12822071 ±  3%     -34.1%    8450822 ±  4%     -33.6%    8517252 ± 
6%     -10.7%   11453675 ±  2%     -10.2%   11513595 ±  2%     -11.6% 
11331657        vm-scalability.throughput
  2.523e+09 ±  3%     -20.7%  2.001e+09 ±  5%     -19.9%  2.021e+09 ± 
7%      +6.8%  2.694e+09 ±  2%      +7.3%  2.707e+09 ±  2%      +5.4% 
2.661e+09        vm-scalability.workload


On 8/22/2020 7:36 AM, Mike Kravetz wrote:
> On 8/21/20 2:02 PM, Mike Kravetz wrote:
>> Would you be willing to test this series on top of 34ae204f1851?  I will need
>> to rebase the series to take the changes made by 34ae204f1851 into account.
> 
> Actually, the series in this thread will apply/run cleanly on top of
> 34ae204f1851.  No need to rebase or port.  If we decide to move forward more
> work is required.  See a few FIXME's in the patches.
> 

-- 
Zhengjun Xing

  reply	other threads:[~2020-10-12  5:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-22  0:55 kernel test robot
2020-06-22 22:01 ` Mike Kravetz
2020-06-25 21:33   ` Mike Kravetz
2020-08-21  8:39     ` [LKP] " Xing Zhengjun
2020-08-21 21:02       ` Mike Kravetz
2020-08-21 23:36         ` Mike Kravetz
2020-10-12  5:29           ` Xing Zhengjun [this message]
2020-10-12 17:40             ` Mike Kravetz
2020-10-13  1:59               ` Xing Zhengjun
2020-10-13  3:01                 ` Mike Kravetz
2020-10-13  6:05                   ` Xing Zhengjun
2020-07-06 20:26 ` [RFC PATCH 0/3] hugetlbfs: address fault time regression Mike Kravetz
2020-07-06 20:26   ` [RFC PATCH 1/3] Revert: "hugetlbfs: Use i_mmap_rwsem to address page fault/truncate race" Mike Kravetz
2020-07-06 20:26   ` [RFC PATCH 2/3] hugetlbfs: Only take i_mmap_rwsem when sharing is possible Mike Kravetz
2020-07-21  0:56     ` [hugetlbfs] 878308e2e0: vm-scalability.throughput 1.2% improvement kernel test robot
2020-07-06 20:26   ` [RFC PATCH 3/3] huegtlbfs: handle page fault/truncate races Mike Kravetz

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=68992a81-a1b9-467b-59c4-48ab65c601c5@linux.intel.com \
    --to=zhengjun.xing@linux.intel.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=dave@stgolabs.net \
    --cc=hughd@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@lists.01.org \
    --cc=mhocko@kernel.org \
    --cc=mike.kravetz@oracle.com \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=prakash.sangappa@oracle.com \
    --cc=rong.a.chen@intel.com \
    --cc=torvalds@linux-foundation.org \
    /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

all inboxes | Powered by JetHome®