Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenBSD is flaky with QEMU on macOS #80

Open
manxorist opened this issue Jan 11, 2024 · 6 comments
Open

OpenBSD is flaky with QEMU on macOS #80

manxorist opened this issue Jan 11, 2024 · 6 comments

Comments

@manxorist
Copy link

manxorist commented Jan 11, 2024

Failing runs:

Working runs (exactly identical configuration):

I did not see such intermittent crashes with xhyve.

@jacob-carlborg
Copy link
Contributor

jacob-carlborg commented Jan 11, 2024

Strange. Different errors for the failing jobs. Could it be running out of memory or some other resource?

I did notice for the successful jobs, it takes 10 minutes to sync the files to the VM. Does it take that long with Xhyve as well?

@manxorist
Copy link
Author

Strange. Different errors for the failing jobs.

It really looks like OpenBSD just running unstable in that VM.

Could it be running out of memory or some other resource?

No, unless the QEMU VM uses vastly more virtual CPUs as the Xhyve VM (I have not checked).

I did notice for the successful jobs, it takes 10 minutes to sync the files to the VM. Does it take that long with Xhyve as well?

typical run on Xhyve: https://github.com/OpenMPT/openmpt/actions/runs/7479081342/job/20355472047

Not sure where I can find that number, I looked at Startup VM total time, which is way faster with Xhyve (3..4min). Installing dependencies is also faster (~9min vs ~12min), but the actual compilation is faster with QEMU. Syncing files and installing dependencies is easily IO-bound, while compilation would be CPU-bound. File IO is notoriously slow on OpenBSD in general, but QEMU cache=unsafe should mitigate most of that, and that should be the default now, unless I misunderstood something.

@jacob-carlborg
Copy link
Contributor

No, unless the QEMU VM uses vastly more virtual CPUs as the Xhyve VM (I have not checked).

It should be the same.

typical run on Xhyve: OpenMPT/openmpt/actions/runs/7479081342/job/20355472047

That takes just two minutes.

Not sure where I can find that number

When viewing a job on GitHub, there's a gear icon in the upper right corner, just after the Search logs input field. If you click that you can select to show timestamps. Then, in the output view, expand the Setting up VM line. Just before the Running command you should see a call to rsync. Just compare the timestamps to the previous line.

but QEMU cache=unsafe should mitigate most of that, and that should be the default now, unless I misunderstood something.

Yes, that's the default.

@manxorist
Copy link
Author

After #47, I do not have any use case for this any more. I am running OpenBSD on QEMU on Ubuntu now, which appears to work fine so far.

@jacob-carlborg
Copy link
Contributor

After #47, I do not have any use case for this any more. I am running OpenBSD on QEMU on Ubuntu now, which appears to work fine so far.

Hmm, interesting. I would expected QEMU to work the same on both macOS and Linux. Unless it's an issue with the hardware acceleration, which will be different.

@manxorist
Copy link
Author

After #47, I do not have any use case for this any more. I am running OpenBSD on QEMU on Ubuntu now, which appears to work fine so far.

Hmm, interesting. I would expected QEMU to work the same on both macOS and Linux. Unless it's an issue with the hardware acceleration, which will be different.

QEMU with Linux KVM probably gets way more testing in practice than QEMU with whatever macOS provides as a acceleration interface,

yorickpeterse added a commit to inko-lang/inko that referenced this issue Apr 27, 2024
For reasons unknown, the VM fails to start up when using qemu, even
though it worked fine before. Per
cross-platform-actions/action#80, it seems
this may also affect other users.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants