GNOME Bugzilla – Bug 695492
Disable SPICE image compression in new VMs
Last modified: 2016-03-31 13:22:07 UTC
See patches
Created attachment 238454 [details] [review] Require libvirt-gconfig >= 0.1.6
Created attachment 238455 [details] [review] vm-configurator: Disable SPICE image compression Since the VMs we create are by default local-only and SPICE server is tied to localhost, it makes a lot of sense to disable image compression as that wastes a lot CPU/battery for no good reason. This patch makes gnome-shell's animations inside VM a lot more smooth. On my system, it actually now feals very much native. Alex pointed out that doing this implies disabling streaming as well, which is not a problem on its own and we probably should be disabling that explicitly as well but unfortunately streaming is required for lipsync in SPICE. However, in practice I see no evidence of lipsync happening anyways. I tested this by playing a high definition (1920x1080) video[1] in fullscreen on different guest OSs (Fedora, Ubuntu, Windows XP and Windows 7) with and without SPICE compression enabled. On all OSs except for Ubuntu, I actually saw improvements in video playback performance, even w.r.t lipsync with compression disabled. On Ubuntu, there were just no significant difference for some reason. [1] http://www.bigbuckbunny.org/index.php/download/
/me tempted to close this bug as a duplicate of #692204...
(In reply to comment #2) > Since the VMs we create are by default local-only and SPICE server is > tied to localhost, it makes a lot of sense to disable image compression > as that wastes a lot CPU/battery for no good reason. Any numbers to back up that 'a lot CPU' ? What is the SPICE bug # for this issue ? > > This patch makes gnome-shell's animations inside VM a lot more smooth. On > my system, it actually now feals very much native. > 'feels' > Alex pointed out that doing this implies disabling streaming as well, > which is not a problem on its own and we probably should be disabling > that explicitly as well but unfortunately streaming is required for > lipsync in SPICE. > > However, in practice I see no evidence of lipsync happening anyways. Bug # ?
(In reply to comment #4) > (In reply to comment #2) > > Since the VMs we create are by default local-only and SPICE server is > > tied to localhost, it makes a lot of sense to disable image compression > > as that wastes a lot CPU/battery for no good reason. > > Any numbers to back up that 'a lot CPU' ? What is the SPICE bug # for this > issue ? That is not the problem on its own. Compression of all sorts uses quite some CPU and when its redundant, it feels a lot already. More so if the combined effect of compression + guest and host CPU usage results in jerky animations. About numbers, I've been in discussing this with Alon for about an year now about this. We have been in agreement that we want to disable compression for local case. The plans was to do this in SPICE itself but I didn't know that we can disable compression already through libvirt/qemu. Just run Fedora 18 guest with and without these patches. The very visible difference should convince you, so no need for numbers (for these patches). :) > > This patch makes gnome-shell's animations inside VM a lot more smooth. On > > my system, it actually now feals very much native. > > > > 'feels' No tearing effect in animations, i-e very smooth. Hence it "feels" native. > > Alex pointed out that doing this implies disabling streaming as well, > > which is not a problem on its own and we probably should be disabling > > that explicitly as well but unfortunately streaming is required for > > lipsync in SPICE. > > > > However, in practice I see no evidence of lipsync happening anyways. > > Bug # ? Haven't filed it but I don't know what the bug will be (yet). The lipsync itself is not broken but AFAICT its getting affected by CPU congession from video/audio decoding in the guest and SPICE doing the same for streaming at the same time. I guess there is a reason why this has been in the roadmap for while now: http://spicespace.org/page/Features/CodecPassthrough
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #2) > > > Since the VMs we create are by default local-only and SPICE server is > > > tied to localhost, it makes a lot of sense to disable image compression > > > as that wastes a lot CPU/battery for no good reason. > > > > Any numbers to back up that 'a lot CPU' ? What is the SPICE bug # for this > > issue ? > > That is not the problem on its own. Compression of all sorts uses quite some > CPU and when its redundant, it feels a lot already. More so if the combined > effect of compression + guest and host CPU usage results in jerky animations. Did Alon tell you that the fact that it uses so much CPU and that when using compression we get jerky animations is the intended result? Or could it be that noone noticed the 'jerky animation when using compression' part, which could mean that we could want to tweak the compression level/cpu use ratio in spice? In the latter case, we need a bug somewhere. > > 'feels' > > No tearing effect in animations, i-e very smooth. Hence it "feels" native. Yes, 'feels', not 'feals' as you spelt it in the log.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #2) > > > > Since the VMs we create are by default local-only and SPICE server is > > > > tied to localhost, it makes a lot of sense to disable image compression > > > > as that wastes a lot CPU/battery for no good reason. > > > > > > Any numbers to back up that 'a lot CPU' ? What is the SPICE bug # for this > > > issue ? > > > > That is not the problem on its own. Compression of all sorts uses quite some > > CPU and when its redundant, it feels a lot already. More so if the combined > > effect of compression + guest and host CPU usage results in jerky animations. > > Did Alon tell you that the fact that it uses so much CPU and that when using > compression we get jerky animations is the intended result? No but one thing is for sure: compresison should not be used for local case. The only "issue" with simply disabling it is lipsync but in practice that is not negatively (but rather positively) affected by disabling compression (at least according to my tests so far with different OSs). > Or could it be that > noone noticed the 'jerky animation when using compression' part, huh? I thought it was a well-known fact. Have you tried gnome 3 running inside a Boxes VM? > which could > mean that we could want to tweak the compression level/cpu use ratio in spice? Probably a good idea but as I said, we shouldn't be using compression for local case anyways as that will waste CPU cycles for no benefit. I'll file bug about decoupling of lipsync from streaming. If that turns out to be impossible, we want to re-enable streaming/compression and work around this limitation by playing with compression options in Boxes. > > > 'feels' > > > > No tearing effect in animations, i-e very smooth. Hence it "feels" native. > > Yes, 'feels', not 'feals' as you spelt it in the log. Ah, didn't realize you were correctly the spelling. :)
(In reply to comment #7) > No but one thing is for sure: compresison should not be used for local case. Of course, but 'compression should not be used for the local case because it's a waste of computing resources' is quite different from 'compression should not be used for the local case because it's harmful to getting a good user experience in the guest'. The latter is news to me, that's why I want to make sure that's a known problem with compression. > > Or could it be that > > noone noticed the 'jerky animation when using compression' part, > > huh? I thought it was a well-known fact. Have you tried gnome 3 running inside > a Boxes VM? I said 'jerky animation when using compression' (in other words 'jerky animation when using compression which goes away when disabling compression'), of course I've seen jerky animation when using spice + gnome-shell, but thus far I've attributed that to llvmpipe slowness, not to SPICE compression. > > > which could > > mean that we could want to tweak the compression level/cpu use ratio in spice? > > Probably a good idea but as I said, we shouldn't be using compression for local > case anyways as that will waste CPU cycles for no benefit. I didn't say we should not disable compression, all I'm saying is "let's work with upstream, and make sure they know about the issues we are having", this is what I'm trying to check here.
(In reply to comment #8) > (In reply to comment #7) > > No but one thing is for sure: compresison should not be used for local case. > > Of course, but 'compression should not be used for the local case because it's > a waste of computing resources' is quite different from 'compression should not > be used for the local case because it's harmful to getting a good user > experience in the guest'. The latter is news to me, that's why I want to make > sure that's a known problem with compression. Its more like combination of both: 'Lets disable compression for local-only VMs as its redundant and we avoid hitting some performance issues at the same time'. > > > Or could it be that > > > noone noticed the 'jerky animation when using compression' part, > > > > huh? I thought it was a well-known fact. Have you tried gnome 3 running inside > > a Boxes VM? > > I said 'jerky animation when using compression' (in other words 'jerky > animation when using compression which goes away when disabling compression'), > of course I've seen jerky animation when using spice + gnome-shell, but thus > far I've attributed that to llvmpipe slowness, not to SPICE compression. Well the both are responsible. Don't think we can do much about llvmpipe but we can and should certainly avoid the SPICE part. Since the latter helps a lot, we then don't even need to worry much about the former. > > > which could > > > mean that we could want to tweak the compression level/cpu use ratio in spice? > > > > Probably a good idea but as I said, we shouldn't be using compression for local > > case anyways as that will waste CPU cycles for no benefit. > > I didn't say we should not disable compression, all I'm saying is "let's work > with upstream, and make sure they know about the issues we are having", this is > what I'm trying to check here. I would count Alon as upstream and this is based on my discussion with him so at least he knows. I think elmarco is also aware of this as he was always right next to us when we discussed this last year at boxes codecamp. But yeah, we should file bugs but thing is that its pretty understandable for me if SPICE doesn't perform well enough when server and client are on the same machine. I am not sure if compression part itself needs any fixing. What do you expect if many entities use the same CPU at the same time? Perhaps the bug should be about the fact that SPICE itself automatically disables compression when server and client are on the same machine.
(In reply to comment #9) > I would count Alon as upstream and this is based on my discussion with him so > at least he knows. This is what I was asking in one previous comment when you answered 'no'... " > Did Alon tell you that the fact that it uses so much CPU and that when using > compression we get jerky animations is the intended result? No" And real life discussions with just one member of the team does not count as 'upstream knows'.
(In reply to comment #10) > (In reply to comment #9) > > I would count Alon as upstream and this is based on my discussion with him so > > at least he knows. > > This is what I was asking in one previous comment when you answered 'no'... > > " > > Did Alon tell you that the fact that it uses so much CPU and that when using > > compression we get jerky animations is the intended result? > > No" > > And real life discussions with just one member of the team does not count as > 'upstream knows'. Count again, there were two. :) And you also forgot to count yourself. :) Anyways, bugs filed: https://bugs.freedesktop.org/show_bug.cgi?id=62188 https://bugs.freedesktop.org/show_bug.cgi?id=62187
(In reply to comment #11) > Anyways, bugs filed: > > https://bugs.freedesktop.org/show_bug.cgi?id=62188 > https://bugs.freedesktop.org/show_bug.cgi?id=62187 *sigh* So you filed 2 feature requests to help you workaround an issue you are seeing, but still no bug for the underlying issue? ('spice + compression + gnome-shell is much worse than spice + no compression + gnome-shell') Or is there already a bug for that? (which is all that I'm asking since the beginning of that bug).
(In reply to comment #12) > (In reply to comment #11) > > Anyways, bugs filed: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=62188 > > https://bugs.freedesktop.org/show_bug.cgi?id=62187 > > *sigh* > So you filed 2 feature requests to help you workaround an issue you are seeing, Work around? I explained in those bug reports why I think they are needed. If you think they are not justifed, feel free to refute/challenge my arguments in there. > but still no bug for the underlying issue? ('spice + compression + gnome-shell > is much worse than spice + no compression + gnome-shell') Or is there already a > bug for that? (which is all that I'm asking since the beginning of that bug). You want read what I said in last para of comment#9.
(In reply to comment #13) > You want read what I said in last para of comment#9. Oh and if you disagree with that, feel free to file the bug yourself. I won't file a bug if I'm not sure there is one.
(In reply to comment #13) > You want read what I said in last para of comment#9. Replied in comment #6 (In reply to comment #14) > Oh and if you disagree with that, feel free to file the bug yourself. I won't > file a bug if I'm not sure there is one. So you don't want to let upstream know about an issue/limitation with SPICE that they may not be aware of?
(In reply to comment #15) > (In reply to comment #13) > > You want read what I said in last para of comment#9. > > Replied in comment #6 No you did not. Let me repeat: I am not at all convinced that shell not performing well when spice compression is enabled is a bug in SPICE. Its very much understandable. I never claimed that SPICE compression is over-using the CPU. Its only using the CPU (as expected) and when combined with other entities using CPU at the same time, you get bad performance. If SPICE compression is using more CPU than it should, I don't have any knowledge about it and I'm certainly not the person to make a judgment about that. > (In reply to comment #14) > > Oh and if you disagree with that, feel free to file the bug yourself. I won't > > file a bug if I'm not sure there is one. > > So you don't want to let upstream know about an issue/limitation with SPICE > that they may not be aware of? I want to file bugs that I have *some* certainty about them being bugs, thats all. Anyways, any comment on the patch itself? Is it good, is it bad? How do I improve it?
(In reply to comment #16) > If SPICE compression is using more CPU than it should, I don't have any > knowledge about it and I'm certainly not the person to make a judgment about > that. And still, you are making that judgement by making the call that upstream needs not be informed about this. > > > (In reply to comment #14) > > So you don't want to let upstream know about an issue/limitation with SPICE > > that they may not be aware of? > > I want to file bugs that I have *some* certainty about them being bugs, thats > all. Please note my choice of word in that last comment, I purposely did not use 'file bugs'.
Hi All, 1. quic / lz compression / decompression can be improved, I'm sure. 2. regardless of #1, not using it at all on a local vm makes sense. 3. regarding discussion upstream - why not discuss it? Zeeshan? a mailing list would probably suit much of this "thread" better :) 4. patch itself makes sense to me, my 2 cents. Alon
(In reply to comment #18) > 4. patch itself makes sense to me, my 2 cents. Yup, I looked at it this morning, but the libvirt-glib API will probably change, so I'm waiting until this is settled for the review.
(In reply to comment #18) > Hi All, > > 1. quic / lz compression / decompression can be improved, I'm sure. Code/algorithms can always be improved, sure but what I was saying was that what I'm seeing is *not necessarily* an issues in compression itself. > 2. regardless of #1, not using it at all on a local vm makes sense. > 3. regarding discussion upstream - why not discuss it? Zeeshan? a mailing list > would probably suit much of this "thread" better :) Yeah, there was this spice developer who promised to work on this last summer but he didn't even discuss this on the mailing list since then. I'm just following his footsteps. :) On a serious note I don't really mind where this gets discussed but personally I prefer something easily traceable with clear life cycle, like a bug in bug tracker.
Created attachment 238791 [details] [review] vm-configurator: Disable SPICE image compression v2: * Adapt to v2 of libvirt-glib patch. * Improved commit log.
Required libvirt-glib API is merged BTW.
Review of attachment 238454 [details] [review]: Given that libvirt-glib 0.1.6 hasn't been released yet, and that you only need one function from there, could that be made optional for now?
Review of attachment 238791 [details] [review]: Looks good, but see my comment on patch 1/2
Review of attachment 238454 [details] [review]: I have talked to Daniel and we are going to have a release on/before Monday so not really an issue.
Review of attachment 238454 [details] [review]: Guess I've been spoiled by Alex's patches in similar situations ;)
(In reply to comment #24) > Review of attachment 238791 [details] [review]: > > Looks good, but see my comment on patch 1 [details]/2 So I'll take this one as an ACK now that other one is ACK'ed?
*** Bug 692204 has been marked as a duplicate of this bug. ***
These have been committed a while ago.