Audio using 90% of assigned CPU on host only, not in vm


Recommended Posts

My windows vm is using about 10-15% at idle but the qemu-system is using around 80% on all the 6 assigned cores to the vm. I tried enabling hyper v but the windows vm just bsod's on boot.

 

Edit: Seems to be an issue with audio decoding using the qemu cpu?? I had youtube/itunes playing in the background and closing chrome/itunes lowered the cpu usage of qemu.

htop_1.png.d868beb735fd07c332e65271501f8647.png

Link to comment

Same here. I am pretty sure, it startet today after upgrading to 6.2 beta 18.

I am monitoring my system through snmp and would have noticed something like that.

 

I just gut 20 mails from due to the high load while waitching a stream on twitch.tv trough "livestreamer". (also http)

So its not just chrome...

A 1080p h264 movie looks similar, but not as bad. vm 10-20% host 30-50%

 

And its not just a wrong measurement, cpu temps were also very high (65°C+ on water)

No other vms/docker were running, and only the 7 cores assigned to this vm were on high load.

 

Your uptime is low as well, did you upgrade as well?

 

I can run 3dmark with normal results, so I also think its video/decoding related...

 

high-cpu.jpg.6985de896274e182f829948748220212.jpg

Link to comment

A little bit more troubleshooting and a ton of luck and I've managed to figure out that it's the audio that is causing huge cpu usage. Disabling all the audio devices causes the cpu usage to drop to almost nothing. No idea how to fix this, I've tried enabling msi interrupts on all the relevant devices but that didn't help

.

Link to comment

I rolled back to 6.1.9 and everything is normal again.

I know thats not helping you, but if our problems are related, maybe the info helps.

 

With 6.2, I had to use mdi-x otherwise sound startet stuttering immediatly. With 6.1.9 mdi-x made no difference. I had 1-2 issues a month.

They said they used some patch to enable hyper-v settings with nvidia passthrough. Maybe that patch is not quite stable.

Link to comment

Not an issue in Windows xp. I might try 8.1 and see if that's better. I was planning to use it for premiere but if audio sucks all the processing power then I'll have to go back to bare metal.

It's not "sucking up" power.  This bug is very misleading in the way it works.

Link to comment

Not an issue in Windows xp. I might try 8.1 and see if that's better. I was planning to use it for premiere but if audio sucks all the processing power then I'll have to go back to bare metal.

It's not "sucking up" power.  This bug is very misleading in the way it works.

Well, it may not slow down the system, but it uses a lot of power and heats up the cpu...

Having a cpu cooler thats runs full speed the time, may very well be disturbing :)

 

And 30-50watts more could be noticable on your power bill in the long run.

 

I don't know why, but out of my 4 Windows VMs, only 2 show the effect. (both SeaBIOS and Windows10 x64 1511)

The 2 other VMs (both OVMF, one Server2012r2 and one Windows10 x64 1507) work fine.

I converted one of the affected SeaBIOS VMs to OVMF, but the issue remained.

So that leaves Win10 x64 1511 or some driver/guest agents as the culprit.

Investigation ongoing ...

 

Btw. adding/removing GPU passthrough did not make any diffrence, so I don't think its the main issue.

 

I am guessing cpu interrupts or context-switches, both seem to really go up (according to vmstat) once I start a video.

I think qemu got a lot of multi-threaded changed under the hood, maybe those threads are running wild in some cases.

I'll collect some data from vmstat in 6.2 and compare it to 6.1, when I find the time for a rollback.

Link to comment

Gents, I have some good news.  We've figured this issue out.  We had to bisect a merge window kernel (NOT FUN) to figure this one out, but we did it.  It will affect all Windows 10 VMs running under QEMU/KVM running on any 4.3.x or 4.4.x branch of the Linux kernel.  Thankfully, we found a way to solve it WITHOUT having to modify the kernel itself.  The next beta will have this resolved.

Link to comment

Gents, I have some good news.  We've figured this issue out.  We had to bisect a merge window kernel (NOT FUN) to figure this one out, but we did it.  It will affect all Windows 10 VMs running under QEMU/KVM running on any 4.3.x or 4.4.x branch of the Linux kernel.  Thankfully, we found a way to solve it WITHOUT having to modify the kernel itself.  The next beta will have this resolved.

Great news and very fast delivery as always!

Sounds like very time consuming and evil sorcery, so thanks for the effort  ;D

 

I'll report back if it helped me.

 

However, squark said he had the issue before upgrading (asuming 6.1.9) and that was a 4.1.18 kernel.

Could he have been affected earlier due to some specific hardware or config?

 

Or he had another issue and I just hijacked his thread  :-[

Link to comment

Gents, I have some good news.  We've figured this issue out.  We had to bisect a merge window kernel (NOT FUN) to figure this one out, but we did it.  It will affect all Windows 10 VMs running under QEMU/KVM running on any 4.3.x or 4.4.x branch of the Linux kernel.  Thankfully, we found a way to solve it WITHOUT having to modify the kernel itself.  The next beta will have this resolved.

 

 

Seriously appreciate the work and looking forward to testing this out in the new build. I had to drop hyper-threading in order to be able to run both gaming win10 vm's and avoid audio issues.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.