On Tue, 18 Feb 2020 at 03:15, Paul Goyette <[email protected]> wrote: > > On Mon, 17 Feb 2020, Michael van Elst wrote: > > > [email protected] (Paul Goyette) writes: > > > >> So, sounds like "something somewhere isn't quite right (tm)". I would > >> have expected a memory allocation failure to automatically trigger some > >> mechanism to reclaim some of the file cache... > > > > It's not the file cache. Freeing the file cache however also cleans up > > other data structures in KVA space and that helps. Something that almost > > always helps is to reduce the value of the kernel variable desiredvnodes > > (you may restore it a few seconds later). > > Would that be ``sysctl kern.maxvnodes'' or some other variable? > > > > Since free memory is not the problem, none of this is triggered > > automatically. > > Got it. > > > +--------------------+--------------------------+-----------------------+ > | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | > | (Retired) | FA29 0E3B 35AF E8AE 6651 | [email protected] | > | Software Developer | 0786 F758 55DE 53BA 7731 | [email protected] | > +--------------------+--------------------------+-----------------------+
I wonder if I hadn't had a problem in the same ballpark a minute ago. On a 20GB laptop, after two days running pkg_rolling-replace, and which also run zfs, I built qemu-4.2 replacing wip/qemu-4.1; the first VM I tried was a Windows Server Next with 4GB memory, which started, but on the rolling dots froze, freezing everything else; the machine still responded to ping, but I was not able to log on the console or break into the debugger with C-S-Esc, so I had to reset it. After that the same VM started without any problem. -- ----
