Tuesday, October 10, 2017

Spent most of my time investigating the source of the huge memory leak in spicy. The background time was used for VM cleanup and restoration on Turbo.

Spicy memory leak

This leak is not entirely obvious, for two reasons:

1. It takes a long time to reproduce, and when it happens, it happens in a sudden "burst"

   # I have only observed it with H264 streaming input. I have only one of these at the moment (since I need the M2000 card), so that means I can only do that with one at a time.

After reproducing a couple of times, enough to confirm with some certainty that it indeed happens in steps (see yesterday's pictures), I tried to narrow the conditions where it happens, without much success.

VM reorganization

After having turned Turbo into a dual-booting machine, I found myself with a lot of VM images laying around that had no VM configuration anymore. So I reconstructed and updated a number of these VMs. I now have running variants of Fedora, Ubuntu and Windows 10. Also, I converted an old (activated) Windows XP image from VMware, to see if I can get it to run under KVM.

I also downloaded a Fedora 27 image, and split my F25 and F26 guests.

I also did the same job on Muse, copying some files around from Turbo. The intent is to reconstruct a 3D VM there to check where I stand with virgl. That had not worked at all last time I tried on Turbo (see Red Hat Bugzilla 1496766).

dnf download bug

On Crazypad, running dnf download did nothing. It downloaded the file, but then I had no file in the current directory. That worked on all my other machines.

That was a transient bug with dnf, fixed by a dnf update.