4 ms·
I'm running 32GB system with two browser VMs getting 4G each. The work VM which is typically connected to Github and work gmail needs to be restarted once ever
by notyourday 6y ago
I'm running 32GB system with two browser VMs getting 4G each.
The work VM which is typically connected to Github and work gmail needs to be restarted once every couple of days.
The play VM which would have a Chromium with a dozen tabs open can can take ~20 min to ~1 hour depending on the content in tabs.
I notice the memory leak when Sublime that I run on the host itself
starts dropping key press speed ( I run "xset r rate 400 50" ). Killing VMs or restarting them makes everything go back to normal.
I've ran glxgears for ~2 hours now with no significant leak. I will probably leave it overnight to see if something as simple as it can be used as a leak example.
I'm going to speculate the key is heavy usage of GLX something that only Chromium does as I have left a desktop with an xterm running top for two days and no leaks were detected on a play vm. So it is not just virtgl in QEMU being exposed to the guest, initialized by the guest and interfaced by the guest via virtio, but actually using virgl on a host to do rendering. Maybe virtual context creation/release cycle?
P.S. I originally made this work on my super light laptop ( i7-6500U with 8G ), so you don't need a beefy rig for it although there's a bug in recent Intel GPU libraries used by mesa that sometimes lock it up. I initially attributed it to something I did but it was not:
https://github.com/qutebrowser/qutebrowser/issues/4641 https://github.com/qutebrowser/qutebrowser/issues/4641
kitty, alacritty, and even Chromium would sometimes lock up with intel iGPUs.
Feel free to reach out - my email address in a profile here. I check it here and there.
- exikyut 6y agoHmm. "Depending on the content in tabs". Might be interesting to graph the leak rate (in KB/min or MB/min) and maybe either record the screen or limit to one or two websites at a time to narrow down what causes the most issues. Besides video playback, CSS animations come to mind as a potential source of GLX acceleration caused by random/mainstream websites. Now I'm wondering what would happen if you fired up multiple tabs with stuff from https://www.shadertoy.com/ https://www.shadertoy.com/, https://experiments.withgoogle.com/collection/chrome https://experiments.withgoogle.com/collection/chrome, https://webglsamples.org/ https://webglsamples.org/, etc >:) Virtual context creation+release could indeed be the problem. FWIW https://github.com/cyrus-and/chrome-remote-interface https://github.com/cyrus-and/chrome-remote-interface makes using Chrome's remote debug protocol (to open and close tabs) utterly trivial; or you could just run multiple concurrent browsers with --user-data-dir=somewhere (probably actually much easier to work with). Chromium aside, another potentially useful trigger may be Unity games - the last(/first/only) time I tried to fire one up my laptop (i5-3360M + HD Graphics 3000) I was scrambling for ^C^C^C while everything slowed to a crawl and the system climbed (impressively quickly) past 97°C ;) (thankfully(!) nothing froze - thanks for the Intel lockup reference), so perhaps that could be a very effective trigger. I'll keep your email address in mind; email is a bit of a long-term sore point due to Gmail constantly slowing everything to a crawl, and I'm currently using 8GB of swap (need to close some tabs) so I replied here so I could respond in a timely manner.