run_command: wait for command to run indefinitely #59
Conversation
This file contains 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
Fixes danobi#40 When both the host and the VM are saturated, the VM may not be scheduled for a while, causing the connection to qga to timeout. Prior to danobi#27 the unix socket would block indefinitely. This change brings back this behaviour while we run a command, and set the timeout back to what it was before running the command. This way, we can give a chance to the host/vm to recover. Tested by running: ``` stress --cpu 256 --io 256 --vm 4 --vm-bytes 1024M --timeout 1000s ``` in the host, and ``` stress --cpu 512 --io 512 --vm 4 --vm-bytes 1024M --timeout 100s & while true; do date; sleep 2; done ``` in the guest. Output showsa that the VM was struggling to run its loop and print the date until the stress tool was done: ``` ===> Setting up VM [ 1.840931] 9pnet: Limiting 'msize' to 512000 as this is the maximum supported by transport virtio ===> Running command Thu Jan 25 01:43:12 PM PST 2024 stress: info: [85] dispatching hogs: 512 cpu, 512 io, 4 vm, 0 hdd [ 5.493242] hrtimer: interrupt took 3387058 ns [ 89.331664] clocksource: timekeeping watchdog on CPU1: hpet wd-wd read-back delay of 31697570ns [ 89.465647] clocksource: wd-tsc-wd read-back delay of 2998850ns, clock-skew test skipped! Thu Jan 25 01:45:00 PM PST 2024 Thu Jan 25 01:45:09 PM PST 2024 Thu Jan 25 01:45:12 PM PST 2024 stress: info: [85] successful run completed in 124s Thu Jan 25 01:45:17 PM PST 2024 Thu Jan 25 01:45:19 PM PST 2024 Thu Jan 25 01:45:21 PM PST 2024 Thu Jan 25 01:45:23 PM PST 2024 Thu Jan 25 01:45:26 PM PST 2024 Thu Jan 25 01:45:28 PM PST 2024 ``` Signed-off-by: Manu Bretelle <chantr4@gmail.com>
danobi
approved these changes
Jan 26, 2024
There was a problem hiding this comment.
seems reasonable to me. (I didn't spend much time thinking deeply about implications tho). @DolceTriade do you have any input?
We could possibly make the timeout configurable through an argument/config. I did not find any reasonable value for it. On the other hand, if one cares about a process going for too long, maybe the responsibility of killing vmtest + qemu can be left to |
DolceTriade
reviewed
Jan 26, 2024
|
ok, I am going to land this then. We can revisit later if we need to set a timeout. Thanks all. |
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.
Fixes #40
When both the host and the VM are saturated, the VM may not be scheduled for a while, causing the connection to qga to timeout.
Prior to #27 the unix socket would block indefinitely.
This change brings back this behaviour while we run a command, and set the timeout back to what it was before running the command. This way, we can give a chance to the host/vm to recover.
Tested by running:
in the host, and
in the guest.
Output showsa that the VM was struggling to run its loop and print the date until the stress tool was done:
Signed-off-by: Manu Bretelle chantr4@gmail.com