tests/boot-sector: Increase timeout to 600 seconds
PATCH 1/1 tests/boot-sector: Increase timeout to 600 seconds
If QEMU has been compiled with the flags --enable-tcg-interpreter and --enable-debug, the guest is running incredibly slow. The pxe boot test can take up to 400 seconds when testing the pseries ppc64 machine. While we should still look for ways to speed up the test on the pseries machine, it's better to increase the timeout in this test to 600 seconds anyway to allow the test to pass successfully now with this unusal configuration already.
--- tests/boot-sector.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
tests/boot-sector.c +2 -2
@@ -137,9 +137,9 @@ void boot_sector_test(void)uint16_t signature;int i; -/* Wait at most 90 seconds */ +/* Wait at most 600 seconds (test is slow with TCI and --enable-debug) */ #define TEST_DELAY (1 * G_USEC_PER_SEC / 10) -#define TEST_CYCLES MAX((90 * G_USEC_PER_SEC / TEST_DELAY), 1) +#define TEST_CYCLES MAX((600 * G_USEC_PER_SEC / TEST_DELAY), 1)/* Poll until code has run and modified memory. Once it has we know BIOS * initialization is done. TODO: check that IP reached the halt
Signature · 1 line
1.8.3.1
Am 22.09.2017 um 05:06 schrieb Thomas Huth:
Quoted 20 lines
If QEMU has been compiled with the flags --enable-tcg-interpreter and --enable-debug, the guest is running incredibly slow. The pxe boot test can take up to 400 seconds when testing the pseries ppc64 machine. While we should still look for ways to speed up the test on the pseries machine, it's better to increase the timeout in this test to 600 seconds anyway to allow the test to pass successfully now with this unusal configuration already.
Signed-off-by Thomas Huth <[email protected]>--- tests/boot-sector.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)tests/boot-sector.c +0
-0@@ -137,9 +137,9 @@ void boot_sector_test(void)uint16_t signature;
tests/boot-sector.c void boot_sector_test(void) · line 145
Quoted 10 lines
tests/boot-sector.c +2
-2int i; -/* Wait at most 90 seconds */ +/* Wait at most 600 seconds (test is slow with TCI and --enable-debug) */ #define TEST_DELAY (1 * G_USEC_PER_SEC / 10) -#define TEST_CYCLES MAX((90 * G_USEC_PER_SEC / TEST_DELAY), 1) +#define TEST_CYCLES MAX((600 * G_USEC_PER_SEC / TEST_DELAY), 1)/* Poll until code has run and modified memory. Once it has we know BIOS * initialization is done. TODO: check that IP reached the halt
cc'ing qemu-trivial
Thanks,
Stefan
Hi Thomas,
Quoted 2 lines · Thomas Huth
If QEMU has been compiled with the flags --enable-tcg-interpreter and --enable-debug, the guest is running incredibly slow. The pxe boot test
There already is a qtest_get_arch(), it might be convenient to have a qtest_get_accel() at some point.
Quoted 28 lines
can take up to 400 seconds when testing the pseries ppc64 machine. While we should still look for ways to speed up the test on the pseries machine, it's better to increase the timeout in this test to 600 seconds anyway to allow the test to pass successfully now with this unusal configuration already.
Signed-off-by Thomas Huth <[email protected]>--- tests/boot-sector.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)tests/boot-sector.c +2
-2@@ -137,9 +137,9 @@ void boot_sector_test(void)uint16_t signature;int i; -/* Wait at most 90 seconds */ +/* Wait at most 600 seconds (test is slow with TCI and --enable-debug) */ #define TEST_DELAY (1 * G_USEC_PER_SEC / 10) -#define TEST_CYCLES MAX((90 * G_USEC_PER_SEC / TEST_DELAY), 1) +#define TEST_CYCLES MAX((600 * G_USEC_PER_SEC / TEST_DELAY), 1)/* Poll until code has run and modified memory. Once it has we know BIOS * initialization is done. TODO: check that IP reached the halt
Quoted 8 lines · Philippe Mathieu-Daudé
Hi Thomas,
Quoted 2 lines · Thomas Huth
If QEMU has been compiled with the flags --enable-tcg-interpreter and --enable-debug, the guest is running incredibly slow. The pxe boot test
There already is a
qtest_get_arch(), it might be convenient to have aqtest_get_accel()at some point.
The "accelerator" (or rather "decelerator") is still TCG in this case - it's just its backend that is so slow.
Anyway, Lukáš recently reported that he could reproduce similar issues with systems that are under heavy stress:
https://marc.info/[email protected]
So I think we should apply this anyway, without any TCI-related checks.
Thomas
Michael Tokarev
AppliedQuoted 7 lines · Thomas Huth
If QEMU has been compiled with the flags --enable-tcg-interpreter and --enable-debug, the guest is running incredibly slow. The pxe boot test can take up to 400 seconds when testing the pseries ppc64 machine. While we should still look for ways to speed up the test on the pseries machine, it's better to increase the timeout in this test to 600 seconds anyway to allow the test to pass successfully now with this unusal configuration already.
Applied to -trivial, thanks!
/mjt
Quoted 9 lines · Michael Tokarev
Quoted 7 lines · Thomas Huth
If QEMU has been compiled with the flags --enable-tcg-interpreter and --enable-debug, the guest is running incredibly slow. The pxe boot test can take up to 400 seconds when testing the pseries ppc64 machine. While we should still look for ways to speed up the test on the pseries machine, it's better to increase the timeout in this test to 600 seconds anyway to allow the test to pass successfully now with this unusal configuration already.
Quoted 3 lines
Applied to -trivial, thanks!
/mjt
Please do not apply this, trivial is not appropriate for functional changes like this.
Quoted 10 lines · Michael S. Tsirkin
Quoted 9 lines · Michael Tokarev
Quoted 7 lines · Thomas Huth
If QEMU has been compiled with the flags --enable-tcg-interpreter and --enable-debug, the guest is running incredibly slow. The pxe boot test can take up to 400 seconds when testing the pseries ppc64 machine. While we should still look for ways to speed up the test on the pseries machine, it's better to increase the timeout in this test to 600 seconds anyway to allow the test to pass successfully now with this unusal configuration already.
Quoted 6 lines
Quoted 3 lines
Applied to -trivial, thanks!
/mjt
Please do not apply this, trivial is not appropriate for functional changes like this.
It's not a functional change, it's just bumping a test timeout. If you think we should be doing something else that's fine (as with any other patch), but in principle I think this is totally fine as a -trivial patch.
thanks
-- PMM
Quoted 18 lines · Peter Maydell
Quoted 10 lines · Michael S. Tsirkin
Quoted 9 lines · Michael Tokarev
Quoted 7 lines · Thomas Huth
If QEMU has been compiled with the flags --enable-tcg-interpreter and --enable-debug, the guest is running incredibly slow. The pxe boot test can take up to 400 seconds when testing the pseries ppc64 machine. While we should still look for ways to speed up the test on the pseries machine, it's better to increase the timeout in this test to 600 seconds anyway to allow the test to pass successfully now with this unusal configuration already.
Quoted 6 lines
Quoted 3 lines
Applied to -trivial, thanks!
/mjt
Please do not apply this, trivial is not appropriate for functional changes like this.
Quoted 7 lines
It's not a functional change, it's just bumping a test timeout. If you think we should be doing something else that's fine (as with any other patch), but in principle I think this is totally fine as a -trivial patch.
thanks
-- PMM
OK. I'd rather not see it applied as-is though.
Signature · 1 line
MST
Quoted 11 lines · Michael S. Tsirkin
Quoted 8 lines · Peter Maydell
Quoted 2 lines · Michael S. Tsirkin
Please do not apply this, trivial is not appropriate for functional changes like this.
It's not a functional change, it's just bumping a test timeout. If you think we should be doing something else that's fine (as with any other patch), but in principle I think this is totally fine as a -trivial patch.
OK. I'd rather not see it applied as-is though.
Oops, looks like it's already hit master (07897000194a). I can revert it if you feel strongly about it, but my personal feeling is that the timeout needs to be long enough that you don't hit it in any configuration. Usually if you're running tests yourself then you'll notice it's stuck before it hits a timeout -- the timeout is just so that fully automated test runs don't hang forever.
thanks
-- PMM
Quoted 9 lines · Thomas Huth
If QEMU has been compiled with the flags --enable-tcg-interpreter and --enable-debug, the guest is running incredibly slow. The pxe boot test can take up to 400 seconds when testing the pseries ppc64 machine. While we should still look for ways to speed up the test on the pseries machine, it's better to increase the timeout in this test to 600 seconds anyway to allow the test to pass successfully now with this unusal configuration already.
Signed-off-by Thomas Huth <[email protected]>
Well I do break things sometimes and I won't be happy about spending 10 minutes waiting for a test to fail.
Can we break out of the test if all CPUs are halted with interrupts disabled?
Quoted 22 lines
--- tests/boot-sector.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)tests/boot-sector.c +2
-2@@ -137,9 +137,9 @@ void boot_sector_test(void)uint16_t signature;int i; -/* Wait at most 90 seconds */ +/* Wait at most 600 seconds (test is slow with TCI and --enable-debug) */ #define TEST_DELAY (1 * G_USEC_PER_SEC / 10) -#define TEST_CYCLES MAX((90 * G_USEC_PER_SEC / TEST_DELAY), 1) +#define TEST_CYCLES MAX((600 * G_USEC_PER_SEC / TEST_DELAY), 1)/* Poll until code has run and modified memory. Once it has we know BIOS * initialization is done. TODO: check that IP reached the halt Signature · 1 line
1.8.3.1
Am 26.09.2017 um 21:30 schrieb Michael S. Tsirkin:
Quoted 9 lines · Thomas Huth
Quoted 8 lines
If QEMU has been compiled with the flags --enable-tcg-interpreter and --enable-debug, the guest is running incredibly slow. The pxe boot test can take up to 400 seconds when testing the pseries ppc64 machine. While we should still look for ways to speed up the test on the pseries machine, it's better to increase the timeout in this test to 600 seconds anyway to allow the test to pass successfully now with this unusal configuration already.
Quoted 7 lines
Quoted 1 line
Signed-off-by Thomas Huth <[email protected]>Well I do break things sometimes and I won't be happy about spending 10 minutes waiting for a test to fail.
Can we break out of the test if all CPUs are halted with interrupts disabled?
Yes, that sounds like a scenario where no more progress can be expected.
Any fixed timeout is either too long (when you expect a failing test) or too short (when you need time for the test to pass).
Would it be possible to get some speed factor (like Linux bogomips) at the beginning of all tests? Then that factor could be used later for all tests which currently use a hard timeout.
Regards
Stefan
Quoted 17 lines · Stefan Weil
Am 26.09.2017 um 21:30 schrieb Michael S. Tsirkin:
Quoted 16 lines · Thomas Huth
Quoted 9 lines
If QEMU has been compiled with the flags --enable-tcg-interpreter and --enable-debug, the guest is running incredibly slow. The pxe boot test can take up to 400 seconds when testing the pseries ppc64 machine. While we should still look for ways to speed up the test on the pseries machine, it's better to increase the timeout in this test to 600 seconds anyway to allow the test to pass successfully now with this unusal configuration already.
Signed-off-by Thomas Huth <[email protected]>Well I do break things sometimes and I won't be happy about spending 10 minutes waiting for a test to fail.
Can we break out of the test if all CPUs are halted with interrupts disabled?
qemu-system-s390x exits automatically in that case (unless you specified the -no-shutdown parameter) ... what about x86?
Another idea: We could run the "info registers" HMP command regularly (is there an equivalent for HMP?) to see whether the guest is still doing something and abort if the all registers stayed the same for, let's say 30 seconds?
Quoted 7 lines
Any fixed timeout is either too long (when you expect a failing test) or too short (when you need time for the test to pass).
Would it be possible to get some speed factor (like Linux bogomips) at the beginning of all tests? Then that factor could be used later for all tests which currently use a hard timeout.
We've got at least three changing factors here: Hardware speed of the host (MHz / bogomips), speed of TCG / the emulated guest (e.g. TCI is slow) and current other workload of the host. Even if we get the first two factors right, the workload of the host can still change very dynamically, so I think it's quite hard to do a good prediction at the beginning of the test here.
Thomas