Re: [LKP] Re: [mm] e6e88712e4: stress-ng.tmpfs.ops_per_sec -69.7% regression
On 11/7/2020 4:55 AM, Matthew Wilcox wrote:
On Mon, Nov 02, 2020 at 01:21:39PM +0800, Rong Chen wrote:
we compared the tmpfs.ops_per_sec: (363 / 103.02) between this commit and
parent commit.
Thanks! I see about a 50% hit on my system, and this patch restores the
performance. Can you verify this works for you?
diff --git a/mm/madvise.c b/mm/madvise.c
index 9b065d412e5f..e602333f8c0d 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -225,7 +225,7 @@ static void force_shm_swapin_readahead(struct
vm_area_struct *vma,
struct address_space *mapping)
{
XA_STATE(xas, >i_pages, linear_page_index(vma, start));
- pgoff_t end_index = end / PAGE_SIZE;
+ pgoff_t end_index = linear_page_index(vma, end + PAGE_SIZE - 1);
struct page *page;
rcu_read_lock();
___
LKP mailing list -- l...@lists.01.org
To unsubscribe send an email to lkp-le...@lists.01.org
I test the patch, the regression is disappeared.
=
tbox_group/testcase/rootfs/kconfig/compiler/nr_threads/disk/testtime/class/cpufreq_governor/ucode:
lkp-csl-2sp3/stress-ng/debian-10.4-x86_64-20200603.cgz/x86_64-rhel-8.3/gcc-9/100%/1HDD/100s/memory/performance/0x42c
commit:
f5df8635c5a3c912919c91be64aa198554b0f9ed
e6e88712e43b7942df451508aafc2f083266f56b
6bc25f0c5e0d55145f7ef087adea2693802a80f3 (this test patch)
f5df8635c5a3c912 e6e88712e43b7942df451508aaf 6bc25f0c5e0d55145f7ef087ade
--- ---
%stddev %change %stddev %change %stddev
\ |\ |\
1198 ± 4% -69.7% 362.67+3.3% 1238 ±
3% stress-ng.tmpfs.ops
11.62 ± 4% -69.7% 3.52+3.4% 12.02 ±
3% stress-ng.tmpfs.ops_per_sec
--
Zhengjun Xing
Re: [mm] e6e88712e4: stress-ng.tmpfs.ops_per_sec -69.7% regression
On Mon, Nov 02, 2020 at 01:21:39PM +0800, Rong Chen wrote:
> we compared the tmpfs.ops_per_sec: (363 / 103.02) between this commit and
> parent commit.
Thanks! I see about a 50% hit on my system, and this patch restores the
performance. Can you verify this works for you?
diff --git a/mm/madvise.c b/mm/madvise.c
index 9b065d412e5f..e602333f8c0d 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -225,7 +225,7 @@ static void force_shm_swapin_readahead(struct
vm_area_struct *vma,
struct address_space *mapping)
{
XA_STATE(xas, >i_pages, linear_page_index(vma, start));
- pgoff_t end_index = end / PAGE_SIZE;
+ pgoff_t end_index = linear_page_index(vma, end + PAGE_SIZE - 1);
struct page *page;
rcu_read_lock();
Re: [mm] e6e88712e4: stress-ng.tmpfs.ops_per_sec -69.7% regression
On Mon, Nov 02, 2020 at 01:21:39PM +0800, Rong Chen wrote: > On 10/30/20 10:58 PM, Matthew Wilcox wrote: > > Can you reproduce this? Here's my results: [snipped] > > Hi Matthew, > > IIUC, yes, we can reproduce it, here is the result from the server: > > $ stress-ng --timeout 100 --times --verify --metrics-brief --sequential 96 > --class memory --minimize --exclude > spawn,exec,swap,stack,atomic,bad-altstack,bsearch,context,full,heapsort,hsearch,judy,lockbus,lsearch,malloc,matrix-3d,matrix,mcontend,membarrier,memcpy,memfd,memrate,memthrash,mergesort,mincore,null,numa,pipe,pipeherd,qsort,radixsort,remap,resources,rmap,shellsort,skiplist,stackmmap,str,stream,tlb-shootdown,tree,tsearch,vm-addr,vm-rw,vm-segv,vm,wcs,zero,zlib > > stress-ng: info: [2765] disabled 'oom-pipe' as it may hang or reboot the > machine (enable it with the --pathological option) > stress-ng: info: [2765] dispatching hogs: 96 tmpfs > stress-ng: info: [2765] successful run completed in 104.67s (1 min, 44.67 > secs) > stress-ng: info: [2765] stressor bogo ops real time usr time sys > time bogo ops/s bogo ops/s > stress-ng: info: [2765] (secs) (secs) (secs) > (real time) (usr+sys time) > stress-ng: info: [2765] tmpfs 363 103.02 622.07 > 7289.85 3.52 0.05 > stress-ng: info: [2765] for a 104.67s run time: > stress-ng: info: [2765] 10047.98s available CPU time > stress-ng: info: [2765] 622.46s user time ( 6.19%) > stress-ng: info: [2765] 7290.66s system time ( 72.56%) > stress-ng: info: [2765] 7913.12s total time ( 78.75%) > stress-ng: info: [2765] load average: 79.62 28.89 10.45 > > we compared the tmpfs.ops_per_sec: (363 / 103.02) between this commit and > parent commit. Ah, so this was the 60-70% regression reported in the subject, not the 100% reported in the body. I'd assumed the latter was the intended message. I'll have another look at this later today. At first glance, I don't see why it _should_ regress. It would seem to be doing fewer atomic operations (avoiding getting the page reference) and walks the XArray more efficiently. I wonder if it's walking the XArray _too_ efficiently -- holding the rcu read lock for too long. I'll try putting a rescheduling point in the middle and see what happens.
Re: [mm] e6e88712e4: stress-ng.tmpfs.ops_per_sec -69.7% regression
On 10/30/20 10:58 PM, Matthew Wilcox wrote: On Fri, Oct 30, 2020 at 10:02:45PM +0800, Chen, Rong A wrote: On 10/30/2020 9:17 PM, Matthew Wilcox wrote: On Fri, Oct 30, 2020 at 03:17:15PM +0800, kernel test robot wrote: Details are as below: --> To reproduce: git clone https://github.com/intel/lkp-tests.git cd lkp-tests bin/lkp install job.yaml # job file is attached in this email bin/lkp run job.yaml Do you actually test these instructions before you send them out? hdd_partitions: "/dev/disk/by-id/ata-WDC_WD2500BEKT-00PVMT0_WD-WX11A23L4840-part 1" ssd_partitions: "/dev/nvme1n1p1 /dev/nvme0n1p1" rootfs_partition: "/dev/disk/by-id/ata-INTEL_SSDSC2CW240A3_CVCV204303WP240CGN-part1" That's _very_ specific to a given machine. I'm not familiar with this test, so I don't know what I need to change. Hi Matthew, Sorry about that, I copied the job.yaml file from the server, the right way to do is to set your disk partitions in the yaml, please see https://github.com/intel/lkp-tests#run-your-own-disk-partitions. there is another reproduce script attached in the original mail for your reference. Can you reproduce this? Here's my results: # stress-ng "--timeout" "100" "--times" "--verify" "--metrics-brief" "--sequential" "96" "--class" "memory" "--minimize" "--exclude" "spawn,exec,swap,stack,atomic,bad-altstack,bsearch,context,full,heapsort,hsearch,judy,lockbus,lsearch,malloc,matrix-3d,matrix,mcontend,membarrier,memcpy,memfd,memrate,memthrash,mergesort,mincore,null,numa,pipe,pipeherd,qsort,radixsort,remap,resources,rmap,shellsort,skiplist,stackmmap,str,stream,tlb-shootdown,tree,tsearch,vm-addr,vm-rw,vm-segv,vm,wcs,zero,zlib" stress-ng: info: [7670] disabled 'oom-pipe' as it may hang or reboot the machine (enable it with the --pathological option) stress-ng: info: [7670] dispatching hogs: 96 tmpfs stress-ng: info: [7670] successful run completed in 100.23s (1 min, 40.23 secs) stress-ng: info: [7670] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s stress-ng: info: [7670] (secs)(secs)(secs) (real time) (usr+sys time) stress-ng: info: [7670] tmpfs 8216100.10368.02230.89 82.0813.72 stress-ng: info: [7670] for a 100.23s run time: stress-ng: info: [7670] 601.38s available CPU time stress-ng: info: [7670] 368.71s user time ( 61.31%) stress-ng: info: [7670] 231.55s system time ( 38.50%) stress-ng: info: [7670] 600.26s total time ( 99.81%) stress-ng: info: [7670] load average: 78.32 27.87 10.10 Hi Matthew, IIUC, yes, we can reproduce it, here is the result from the server: $ stress-ng --timeout 100 --times --verify --metrics-brief --sequential 96 --class memory --minimize --exclude spawn,exec,swap,stack,atomic,bad-altstack,bsearch,context,full,heapsort,hsearch,judy,lockbus,lsearch,malloc,matrix-3d,matrix,mcontend,membarrier,memcpy,memfd,memrate,memthrash,mergesort,mincore,null,numa,pipe,pipeherd,qsort,radixsort,remap,resources,rmap,shellsort,skiplist,stackmmap,str,stream,tlb-shootdown,tree,tsearch,vm-addr,vm-rw,vm-segv,vm,wcs,zero,zlib stress-ng: info: [2765] disabled 'oom-pipe' as it may hang or reboot the machine (enable it with the --pathological option) stress-ng: info: [2765] dispatching hogs: 96 tmpfs stress-ng: info: [2765] successful run completed in 104.67s (1 min, 44.67 secs) stress-ng: info: [2765] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s stress-ng: info: [2765] (secs) (secs) (secs) (real time) (usr+sys time) stress-ng: info: [2765] tmpfs 363 103.02 622.07 7289.85 3.52 0.05 stress-ng: info: [2765] for a 104.67s run time: stress-ng: info: [2765] 10047.98s available CPU time stress-ng: info: [2765] 622.46s user time ( 6.19%) stress-ng: info: [2765] 7290.66s system time ( 72.56%) stress-ng: info: [2765] 7913.12s total time ( 78.75%) stress-ng: info: [2765] load average: 79.62 28.89 10.45 we compared the tmpfs.ops_per_sec: (363 / 103.02) between this commit and parent commit. Best Regards, Rong Chen
Re: [LKP] Re: [mm] e6e88712e4: stress-ng.tmpfs.ops_per_sec -69.7% regression
On Fri, Oct 30, 2020 at 02:58:35PM +, Matthew Wilcox wrote: > On Fri, Oct 30, 2020 at 10:02:45PM +0800, Chen, Rong A wrote: > > On 10/30/2020 9:17 PM, Matthew Wilcox wrote: > > > On Fri, Oct 30, 2020 at 03:17:15PM +0800, kernel test robot wrote: > > > > Details are as below: > > > > --> > > > > > > > > > > > > To reproduce: > > > > > > > > git clone https://github.com/intel/lkp-tests.git > > > > cd lkp-tests > > > > bin/lkp install job.yaml # job file is attached in this email > > > > bin/lkp run job.yaml > > > > > > Do you actually test these instructions before you send them out? > > > > > > hdd_partitions: > > > "/dev/disk/by-id/ata-WDC_WD2500BEKT-00PVMT0_WD-WX11A23L4840-part > > > 1" > > > ssd_partitions: "/dev/nvme1n1p1 /dev/nvme0n1p1" > > > rootfs_partition: > > > "/dev/disk/by-id/ata-INTEL_SSDSC2CW240A3_CVCV204303WP240CGN-part1" > > > > > > That's _very_ specific to a given machine. I'm not familiar with > > > this test, so I don't know what I need to change. > > > > > > Hi Matthew, > > > > Sorry about that, I copied the job.yaml file from the server, > > the right way to do is to set your disk partitions in the yaml, > > please see https://github.com/intel/lkp-tests#run-your-own-disk-partitions. > > > > there is another reproduce script attached in the original mail > > for your reference. > > Can you reproduce this? Here's my results: thanks for quick check, we will provide update right after the weekend. Sorry for any inconvenience for the reproduction side so far. We need to improve this part. > > # stress-ng "--timeout" "100" "--times" "--verify" "--metrics-brief" > "--sequential" "96" "--class" "memory" "--minimize" "--exclude" > "spawn,exec,swap,stack,atomic,bad-altstack,bsearch,context,full,heapsort,hsearch,judy,lockbus,lsearch,malloc,matrix-3d,matrix,mcontend,membarrier,memcpy,memfd,memrate,memthrash,mergesort,mincore,null,numa,pipe,pipeherd,qsort,radixsort,remap,resources,rmap,shellsort,skiplist,stackmmap,str,stream,tlb-shootdown,tree,tsearch,vm-addr,vm-rw,vm-segv,vm,wcs,zero,zlib" > stress-ng: info: [7670] disabled 'oom-pipe' as it may hang or reboot the > machine (enable it with the --pathological option) > stress-ng: info: [7670] dispatching hogs: 96 tmpfs > stress-ng: info: [7670] successful run completed in 100.23s (1 min, 40.23 > secs) > stress-ng: info: [7670] stressor bogo ops real time usr time sys > time bogo ops/s bogo ops/s > stress-ng: info: [7670] (secs)(secs)(secs) > (real time) (usr+sys time) > stress-ng: info: [7670] tmpfs 8216100.10368.02 > 230.8982.0813.72 > stress-ng: info: [7670] for a 100.23s run time: > stress-ng: info: [7670] 601.38s available CPU time > stress-ng: info: [7670] 368.71s user time ( 61.31%) > stress-ng: info: [7670] 231.55s system time ( 38.50%) > stress-ng: info: [7670] 600.26s total time ( 99.81%) > stress-ng: info: [7670] load average: 78.32 27.87 10.10 > ___ > LKP mailing list -- l...@lists.01.org > To unsubscribe send an email to lkp-le...@lists.01.org
Re: [mm] e6e88712e4: stress-ng.tmpfs.ops_per_sec -69.7% regression
On Fri, Oct 30, 2020 at 10:02:45PM +0800, Chen, Rong A wrote: > On 10/30/2020 9:17 PM, Matthew Wilcox wrote: > > On Fri, Oct 30, 2020 at 03:17:15PM +0800, kernel test robot wrote: > > > Details are as below: > > > --> > > > > > > > > > To reproduce: > > > > > > git clone https://github.com/intel/lkp-tests.git > > > cd lkp-tests > > > bin/lkp install job.yaml # job file is attached in this email > > > bin/lkp run job.yaml > > > > Do you actually test these instructions before you send them out? > > > > hdd_partitions: > > "/dev/disk/by-id/ata-WDC_WD2500BEKT-00PVMT0_WD-WX11A23L4840-part > > 1" > > ssd_partitions: "/dev/nvme1n1p1 /dev/nvme0n1p1" > > rootfs_partition: > > "/dev/disk/by-id/ata-INTEL_SSDSC2CW240A3_CVCV204303WP240CGN-part1" > > > > That's _very_ specific to a given machine. I'm not familiar with > > this test, so I don't know what I need to change. > > > Hi Matthew, > > Sorry about that, I copied the job.yaml file from the server, > the right way to do is to set your disk partitions in the yaml, > please see https://github.com/intel/lkp-tests#run-your-own-disk-partitions. > > there is another reproduce script attached in the original mail > for your reference. Can you reproduce this? Here's my results: # stress-ng "--timeout" "100" "--times" "--verify" "--metrics-brief" "--sequential" "96" "--class" "memory" "--minimize" "--exclude" "spawn,exec,swap,stack,atomic,bad-altstack,bsearch,context,full,heapsort,hsearch,judy,lockbus,lsearch,malloc,matrix-3d,matrix,mcontend,membarrier,memcpy,memfd,memrate,memthrash,mergesort,mincore,null,numa,pipe,pipeherd,qsort,radixsort,remap,resources,rmap,shellsort,skiplist,stackmmap,str,stream,tlb-shootdown,tree,tsearch,vm-addr,vm-rw,vm-segv,vm,wcs,zero,zlib" stress-ng: info: [7670] disabled 'oom-pipe' as it may hang or reboot the machine (enable it with the --pathological option) stress-ng: info: [7670] dispatching hogs: 96 tmpfs stress-ng: info: [7670] successful run completed in 100.23s (1 min, 40.23 secs) stress-ng: info: [7670] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s stress-ng: info: [7670] (secs)(secs)(secs) (real time) (usr+sys time) stress-ng: info: [7670] tmpfs 8216100.10368.02230.89 82.0813.72 stress-ng: info: [7670] for a 100.23s run time: stress-ng: info: [7670] 601.38s available CPU time stress-ng: info: [7670] 368.71s user time ( 61.31%) stress-ng: info: [7670] 231.55s system time ( 38.50%) stress-ng: info: [7670] 600.26s total time ( 99.81%) stress-ng: info: [7670] load average: 78.32 27.87 10.10
Re: [mm] e6e88712e4: stress-ng.tmpfs.ops_per_sec -69.7% regression
On 10/30/2020 9:17 PM, Matthew Wilcox wrote: On Fri, Oct 30, 2020 at 03:17:15PM +0800, kernel test robot wrote: Details are as below: --> To reproduce: git clone https://github.com/intel/lkp-tests.git cd lkp-tests bin/lkp install job.yaml # job file is attached in this email bin/lkp run job.yaml Do you actually test these instructions before you send them out? hdd_partitions: "/dev/disk/by-id/ata-WDC_WD2500BEKT-00PVMT0_WD-WX11A23L4840-part 1" ssd_partitions: "/dev/nvme1n1p1 /dev/nvme0n1p1" rootfs_partition: "/dev/disk/by-id/ata-INTEL_SSDSC2CW240A3_CVCV204303WP240CGN-part1" That's _very_ specific to a given machine. I'm not familiar with this test, so I don't know what I need to change. Hi Matthew, Sorry about that, I copied the job.yaml file from the server, the right way to do is to set your disk partitions in the yaml, please see https://github.com/intel/lkp-tests#run-your-own-disk-partitions. there is another reproduce script attached in the original mail for your reference. Best Regards, Rong Chen [snipped 4000 lines of gunk]
Re: [mm] e6e88712e4: stress-ng.tmpfs.ops_per_sec -69.7% regression
On Fri, Oct 30, 2020 at 03:17:15PM +0800, kernel test robot wrote: > Details are as below: > --> > > > To reproduce: > > git clone https://github.com/intel/lkp-tests.git > cd lkp-tests > bin/lkp install job.yaml # job file is attached in this email > bin/lkp run job.yaml Do you actually test these instructions before you send them out? hdd_partitions: "/dev/disk/by-id/ata-WDC_WD2500BEKT-00PVMT0_WD-WX11A23L4840-part 1" ssd_partitions: "/dev/nvme1n1p1 /dev/nvme0n1p1" rootfs_partition: "/dev/disk/by-id/ata-INTEL_SSDSC2CW240A3_CVCV204303WP240CGN-part1" That's _very_ specific to a given machine. I'm not familiar with this test, so I don't know what I need to change. [snipped 4000 lines of gunk]
