dio: reduce the number of cycles
PATCH 1/1 dio: reduce the number of cycles
These two cases (dio29/30) takes a bit long time in dio test, but they're not stress test, so I suggest reducing the number of cycles.
On my RHEL-7.3 (23G RAM, 24 CPU(s), x86_64) box, it takes almost 9 mins.
diotest06 1 TPASS : Read with Direct IO, Write without diotest06 2 TPASS : Write with Direct IO, Read without diotest06 3 TPASS : Read, Write with Direct IO diotest06 0 TINFO : 3 testblocks 1000 iterations with 100 children completed
real 8m4.805s
user 71m36.722s
sys 8m51.649s
--- runtest/dio | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
runtest/dio +2 -2
@@ -40,8 +40,8 @@ dio27 diotest6 -b 8192 -o 1024000 -i 1000 -v 100 dio28 diotest6 -b 8192 -o 1024000 -i 1000 -v 200 ### Run the tests with more children -dio29 diotest3 -b 65536 -n 100 -i 1000 -o 1024000 -dio30 diotest6 -b 65536 -n 100 -i 1000 -o 1024000 +dio29 diotest3 -b 65536 -n 100 -i 100 -o 1024000 +dio30 diotest6 -b 65536 -n 100 -i 100 -o 1024000 # # RAW DEVICE TEST SECTION # DEV1 and DEV2 should be exported prior to execution or
Signature · 1 line
2.9.3
PATCH 1/1 dio: reduce the number of cycles
Quoted 10 lines · Li Wang
These two cases (dio29/30) takes a bit long time in dio test, but they're not stress test, so I suggest reducing the number of cycles.
On my RHEL-7.3 (23G RAM, 24 CPU(s),
x86_64) box, it takes almost 9 mins.diotest06 1 TPASS : Read with Direct IO, Write without diotest06 2 TPASS : Write with Direct IO, Read without diotest06 3 TPASS : Read, Write with Direct IO diotest06 0 TINFO : 3 testblocks 1000 iterations with 100 children completed
Quoted 5 lines
real 8m4.805s
user 71m36.722s
sys 8m51.649sSigned-off-by Li Wang <[email protected]>
I tested diotest30 with 100 iterations and it still could reproduce the bug I was seeing on 4.10 kernel quite reliably (even if not 100%), so
Quoted 22 lines
--- runtest/dio | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)runtest/dio +2
-2@@ -40,8 +40,8 @@ dio27 diotest6 -b 8192 -o 1024000 -i 1000 -v 100 dio28 diotest6 -b 8192 -o 1024000 -i 1000 -v 200 ### Run the tests with more children -dio29 diotest3 -b 65536 -n 100 -i 1000 -o 1024000 -dio30 diotest6 -b 65536 -n 100 -i 1000 -o 1024000 +dio29 diotest3 -b 65536 -n 100 -i 100 -o 1024000 +dio30 diotest6 -b 65536 -n 100 -i 100 -o 1024000 # # RAW DEVICE TEST SECTION # DEV1 and DEV2 should be exported prior to execution orSignature · 1 line
2.9.3
PATCH 1/1 dio: reduce the number of cycles
Hi!
Quoted 4 lines
I tested diotest30 with 100 iterations and it still could reproduce the bug I was seeing on 4.10 kernel quite reliably (even if not 100%), so
Acked-by Eryu Guan <[email protected]>
What's the reliability after the patch btw? What is the actual percentage of undetected failures for at least 10 runs of the test?
Signature · 2 lines
Cyril Hrubis [email protected]
PATCH 1/1 dio: reduce the number of cycles
Quoted 8 lines · Cyril Hrubis
Hi!
Quoted 4 lines
I tested diotest30 with 100 iterations and it still could reproduce the bug I was seeing on 4.10 kernel quite reliably (even if not 100%), so
Acked-by Eryu Guan <[email protected]>What's the reliability after the patch btw? What is the actual percentage of undetected failures for at least 10 runs of the test?
I ran diotest30 10 times with "-i 100" and 8 of them failed. IIRC, it was not 100% reproduced either when I first saw the test failure in 4.10-rc kernel testing. So I think ~80% probability to reproduce is fine.
Thanks,
Eryu
PATCH 1/1 dio: reduce the number of cycles
Hi!
Quoted 7 lines
Quoted 2 lines
What's the reliability after the patch btw? What is the actual percentage of undetected failures for at least 10 runs of the test?
I ran diotest30 10 times with "-i 100" and 8 of them failed. IIRC, it was not 100% reproduced either when I first saw the test failure in 4.10-rc kernel testing. So I think ~80% probability to reproduce is fine.
Fair enough I've added this paragraph to the commit message and pushed, thanks.
Signature · 2 lines
Cyril Hrubis [email protected]
PATCH 1/1 dio: reduce the number of cycles
Quoted 11 lines · Cyril Hrubis
Hi!
Quoted 7 lines
Quoted 2 lines
What's the reliability after the patch btw? What is the actual percentage of undetected failures for at least 10 runs of the test?
I ran diotest30 10 times with "-i 100" and 8 of them failed. IIRC, it was not 100% reproduced either when I first saw the test failure in 4.10-rc kernel testing. So I think ~80% probability to reproduce is fine.
Fair enough I've added this paragraph to the commit message and pushed, thanks.
Hmm, it does not takes about 100 minutes, without this change, it takes almost 9mins. After applying, only 50secs.
That's probably my description misleading you, sorry about that. Since you have already submitted this patch, so, let it go.
=============
commit b246897a5a8e31b47442d15d7854a0eb8e64e949
Author: Li Wang <[email protected]> Date: Wed Jun 14 11:38:30 2017 +0800
dio: reduce the number of cycles
These two cases (dio29/30) takes about 100 minutes, but they're not stress test, so I suggest reducing the number of cycles.
After the change on my RHEL-7.3 (23G RAM, 24 CPU(s), x86_64) box, it still takes almost 9 mins.
diotest06 1 TPASS : Read with Direct IO, Write without
diotest06 2 TPASS : Write with Direct IO, Read without
diotest06 3 TPASS : Read, Write with Direct IO
diotest06 0 TINFO : 3 testblocks 1000 iterations with 100
children completed
real 8m4.805s
user 71m36.722s
sys 8m51.649s==============
Signature · 2 lines
Li Wang [email protected]
PATCH 1/1 dio: reduce the number of cycles
Hi!
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
What's the reliability after the patch btw? What is the actual percentage of undetected failures for at least 10 runs of the test?
I ran diotest30 10 times with "-i 100" and 8 of them failed. IIRC, it was not 100% reproduced either when I first saw the test failure in 4.10-rc kernel testing. So I think ~80% probability to reproduce is fine.
Quoted 8 lines
Quoted 2 lines
Fair enough I've added this paragraph to the commit message and pushed, thanks.
Hmm, it does not takes about 100 minutes, without this change, it takes almost 9mins. After applying, only 50secs.
That's probably my description misleading you, sorry about that. Since you have already submitted this patch, so, let it go.
Strange, it does take about ~10 minutes after the patch is applied for me and about ~100 before at least for diotest6, diotest3 is a bit faster with ~20 minutes before and ~4 minutes after. That is on NUMA machine with 24 CPUs and 16GB RAM and /tmp on Btrfs.
The diotest6 appears to be taking about ~45 minutes in our automated framework before this patch and diotest3 takes about 3 minutes.
On my workstation the diotest3 takes ~5 minutes after the patch and diotest06 takes ~45 minutes. That is much more modest machine with just 4GB RAM and 4 CPUs.
So I would say that the resulting time depends on many factors, most notably the underlying I/O device, fileystem, number of CPUs and RAM.
Signature · 2 lines
Cyril Hrubis [email protected]