[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7540556c-1e07-51b2-d903-829a887ef5b6@oracle.com>
Date: Mon, 12 Oct 2020 10:40:40 -0700
From: Mike Kravetz <mike.kravetz@...cle.com>
To: Xing Zhengjun <zhengjun.xing@...ux.intel.com>,
kernel test robot <rong.a.chen@...el.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...nel.org>,
Hugh Dickins <hughd@...gle.com>,
Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
Andrea Arcangeli <aarcange@...hat.com>,
"Kirill A.Shutemov" <kirill.shutemov@...ux.intel.com>,
Davidlohr Bueso <dave@...olabs.net>,
Prakash Sangappa <prakash.sangappa@...cle.com>,
LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org
Subject: Re: [LKP] Re: [hugetlbfs] c0d0381ade: vm-scalability.throughput
-33.4% regression
On 10/11/20 10:29 PM, Xing Zhengjun wrote:
> 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.
>
Thank you for testing.
Just curious, did you apply the series in this thread or just test v5.9-rc8?
If just testing v5.9-rc8, no changes to this code were added after 34ae204f1851,
so results being the same are expected.
There are some functional issues with this new hugetlb locking model that
are currently being worked. It is likely to result in significantly different
code. The performance issues discovered here will be taken into account with
the new code. However, as previously mentioned additional synchronization
is required for functional correctness. As a result, there will be some
regression in this code.
--
Mike Kravetz
> =========================================================================================
> 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.
>>
Powered by blists - more mailing lists