| Message ID | 20240611034058.12611-2-xufeifei1@oppo.com |
|---|---|
| State | Rejected |
| Headers | show |
| Series | Reduce loop count to meet need of low performance terminals | expand |
Hi! > --- a/runtest/sched > +++ b/runtest/sched > @@ -9,7 +9,7 @@ trace_sched01 trace_sched -c 1 > cfs_bandwidth01 cfs_bandwidth01 -i 5 > hackbench01 hackbench 50 process 1000 > hackbench02 hackbench 20 thread 1000 > -starvation starvation > +starvation starvation -l 100000 Are you sure that your kernel isn't affected by the bug the test checks for? The test timeouts on a buggy kernel. How long does the test run if you disable timeouts (by setting static int timeout = -1 in the source)? Also what kind of system it is? How fast is the CPU?
Are you sure that your kernel isn't affected by the bug the test checks for? The test timeouts on a buggy kernel. -- Is there any place where I can see more relevant information? which kind of bug you have found? the test timeout on myside where there still 640000 loop, ZZL pid = 29466 this is while 646533 times loop = 646533 ------- ZZL pid = 29466 this is while 646532 times loop = 646532 ------- ZZL pid = 29466 this is while 646531 times loop = 646531 ------- ZZL pid = 29466 this is while 646530 times loop = 646530 ------- ZZL pid = 29466 this is while 646529 times loop = 646529 ------- ZZL pid = 29466 this is while 646528 times loop = 646528 ------- ZZL pid = 29466 this is while 646527 times loop = 646527 ------- ZZL pid = 29466 this is while 646526 times loop = 646526 ------- ZZL pid = 29466 this is while 646525 times loop = 646525 ------- ZZL pid = 29466 this is while 646524 times loop = 646524 ------- ZZL pid = 29466 this is while 646523 times loop = 646523 ------- ZZL pid = 29466 this is while 646522 times loop = 646522 ------- ZZL pid = 29466 this is while 646521 times loop = 646521 ------- Test timeouted, sending SIGKILL! external/ltp/lib/tst_test.c:1641: TINFO: Killed the leftover descendant processes external/ltp/lib/tst_test.c:1648: TINFO: If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1 external/ltp/lib/tst_test.c:1649: TBROK: Test killed! (timeout?) Summary: passed 1 failed 0 broken 1 skipped 0 warnings 0 How long does the test run if you disable timeouts (by setting static int timeout = -1 in the source)? -- about 370 seconds Also what kind of system it is? How fast is the CPU? --android 14 , kenrel 6.1.43-android14-11-o-g9bbfe9009b86 , cat /proc/cpuinfo processor : 0 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x2 CPU part : 0xd05 （ARM_CPU_PART_CORTEX_A55) CPU revision : 0 cpu chip -----邮件原件----- 发件人: Cyril Hrubis <chrubis@suse.cz> 发送时间: 2024年6月11日 19:41 收件人: 徐飞飞(Steve) <xufeifei1@oppo.com> 抄送: ltp@lists.linux.it 主题: Re: [LTP] [PATCH] Reduce loop count to meet need of low performance terminals 外部邮件/External Mail Hi! > --- a/runtest/sched > +++ b/runtest/sched > @@ -9,7 +9,7 @@ trace_sched01 trace_sched -c 1 > cfs_bandwidth01 cfs_bandwidth01 -i 5 > hackbench01 hackbench 50 process 1000 > hackbench02 hackbench 20 thread 1000 > -starvation starvation > +starvation starvation -l 100000 Are you sure that your kernel isn't affected by the bug the test checks for? The test timeouts on a buggy kernel. How long does the test run if you disable timeouts (by setting static int timeout = -1 in the source)? Also what kind of system it is? How fast is the CPU? -- Cyril Hrubis chrubis@suse.cz
Hi! > Are you sure that your kernel isn't affected by the bug the test checks for? The test timeouts on a buggy kernel. > -- Is there any place where I can see more relevant information? which kind of bug you have found? It's right in the top level comment in the testcase source where the test description is. > the test timeout on myside where there still 640000 loop, > ZZL pid = 29466 this is while 646533 times loop = 646533 ------- > ZZL pid = 29466 this is while 646532 times loop = 646532 ------- > ZZL pid = 29466 this is while 646531 times loop = 646531 ------- > ZZL pid = 29466 this is while 646530 times loop = 646530 ------- > ZZL pid = 29466 this is while 646529 times loop = 646529 ------- > ZZL pid = 29466 this is while 646528 times loop = 646528 ------- > ZZL pid = 29466 this is while 646527 times loop = 646527 ------- > ZZL pid = 29466 this is while 646526 times loop = 646526 ------- > ZZL pid = 29466 this is while 646525 times loop = 646525 ------- > ZZL pid = 29466 this is while 646524 times loop = 646524 ------- > ZZL pid = 29466 this is while 646523 times loop = 646523 ------- > ZZL pid = 29466 this is while 646522 times loop = 646522 ------- > ZZL pid = 29466 this is while 646521 times loop = 646521 ------- > Test timeouted, sending SIGKILL! > external/ltp/lib/tst_test.c:1641: TINFO: Killed the leftover descendant processes > external/ltp/lib/tst_test.c:1648: TINFO: If you are running on slow machine, try exporting LTP_TIMEOUT_MUL > 1 > external/ltp/lib/tst_test.c:1649: TBROK: Test killed! (timeout?) > > Summary: > passed 1 > failed 0 > broken 1 > skipped 0 > warnings 0 > > > How long does the test run if you disable timeouts (by setting static int timeout = -1 in the source)? > -- about 370 seconds Looking at this it seems that your CPU is just a bit slower, if the test fails it's supposed to be at least one order of magnitude slower. > Also what kind of system it is? How fast is the CPU? > --android 14 , kenrel 6.1.43-android14-11-o-g9bbfe9009b86 , > > cat /proc/cpuinfo > processor : 0 > BogoMIPS : 38.40 > Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp > CPU implementer : 0x41 > CPU architecture: 8 > CPU variant : 0x2 > CPU part : 0xd05 （ARM_CPU_PART_CORTEX_A55) > CPU revision : 0 So this is single core ARM cortex A55, it really seems to be just a case of slower procesor, so it does make sense to lower the number of iterations or increase the test timeout. However the problem is that if we divide the default number of iterations by two and keep the timeout the test would stil pass even on broken kernel on an x86_64 desktop. So we probably need a callibration loop that would be able to estimate the CPU speed to set the expectations right.
diff --git a/runtest/sched b/runtest/sched index 5dab7a4c2..02a77040c 100644 --- a/runtest/sched +++ b/runtest/sched @@ -9,7 +9,7 @@ trace_sched01 trace_sched -c 1 cfs_bandwidth01 cfs_bandwidth01 -i 5 hackbench01 hackbench 50 process 1000 hackbench02 hackbench 20 thread 1000 -starvation starvation +starvation starvation -l 100000 proc_sched_rt01 proc_sched_rt01
Signed-off-by: xufeifei <xufeifei1@oppo.com> --- runtest/sched | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.17.1