Fix a timeout problem in the block_check_memory_leak test on s390x#4441
Closed
huth wants to merge 1 commit intoautotest:masterfrom
Closed
Fix a timeout problem in the block_check_memory_leak test on s390x#4441huth wants to merge 1 commit intoautotest:masterfrom
huth wants to merge 1 commit intoautotest:masterfrom
Conversation
Since valgrind is instrumenting the application (memory accesses are examined, and the binary code of the application is JIT recompiled), this can cause massive slowdowns of QEMU. On s390x, when the guest is configured with a virtio-gpu device and the guest is writing its boot messages to that device, too (i.e. when Plymouth in the guest writes all boot messages to the graphical console), these slowdowns are even so high that they can cause some timeouts in systemd of the guest, so that the boot process of the guest fails. To still be able to run the block_check_memory_leak on s390x, too, let's disable the virtio-gpu device here to avoid the systemd timeouts. The test is about checking for memory leaks in the block layer, so disabling the graphical console should not change the target area of this test. Buglink: https://issues.redhat.com/browse/RHEL-102982 Signed-off-by: Thomas Huth <thuth@redhat.com>
WalkthroughA new s390x-specific architecture configuration was added to the block_check_memory_leak.cfg file, setting Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Author
|
This is not working reliably, I need to reconsider, so I'm closing this PR again |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Since valgrind is instrumenting the application (memory accesses are examined, and the binary code of the application is JIT recompiled), this can cause massive slowdowns of QEMU. On s390x, when the guest is configured with a virtio-gpu device and the guest is writing its boot messages to that device, too (i.e. when Plymouth in the guest writes all boot messages to the graphical console), these slowdowns are even so high that they can cause some timeouts in systemd of the guest, so that the boot process of the guest fails.
To still be able to run the block_check_memory_leak on s390x, too, let's disable the virtio-gpu device here to avoid the systemd timeouts. The test is about checking for memory leaks in the block layer, so disabling the graphical console should not change the target area of this test.
Buglink: https://issues.redhat.com/browse/RHEL-102982
ID: 5049
Summary by CodeRabbit