Memory management changes after kernel update on 6-Aug

[Mark Johnston]

On Fri, Aug 09, 2019 at 01:05:50PM -0700, Kevin Oberman wrote:
> On Fri, Aug 9, 2019 at 11:35 AM Mark Johnston <markj at freebsd.org> wrote:
> 
> > On Fri, Aug 09, 2019 at 11:09:24AM -0700, Kevin Oberman wrote:
> > > Since I updated my 12.0-STABLE system on 6-Aug I have been seeing issues
> > > resuming my Win7 VM on VirtualBox. My prior kernel was built on 24-Jul.
> > If
> > > there is not sufficient memory available to reload the system (4 Meg.),
> > the
> >
> > Where does this number come from?  What memory usage stats do you see in
> > top(1) when the error occurs?
> >
> 
> I am monitoring memory usage with gkrellm. It appears to define "Free" as
> the sum of "Inactive" and "Free". If you are referring to size of the VM,
> was supposed to be the memory specified when I created the VM, but my
> fingers got ahead of my brain and it should have been 4G, not 4M. Hey!
> What's a few orders of magnitude?
> 
> Oddly, when I watch memory space closely I note that, as the VM loads, I
> started seeing swap utilization increase as free space was exhausted at
> about 80% loaded. Loading continued to 98%. at that point loading stopped
> and swap use continued to grow for a bit. Then free space started to
> increase from about 300M to about 700M before the error window popped up.
> 
> 
> > > resume fails with a message that memory was exhausted. Usually I can try
> > > resuming again and it will work. Sometimes I get the error two or three
> > > times before the system resumes.
> >
> > What exactly is the error message?
> >
> Failed to open a session for the virtual machine Win7.
> 
> Failed to load unit 'pgm' (VERR_EM_NO_MEMORY).
> 
> Result Code: NS_ERROR_FAILURE (0x80004005)
> Component: ConsoleWrap
> Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}
> 
> 
> >
> > > Since I have not touched VirtualBox other than to rebuild the kmod after
> > > the kernel build, it looks like something in the OS triggered this. Since
> > > the system frees up some memory each time so that the VM eventually
> > > resumes, it looks like the memory request is made to the OS, but VB is
> > not
> > > waiting or not enough memory is freed to allow the VB to complete the
> > > resume.
> > >
> > > Any clue what might have changed over those 13 days? I am running GENERIC
> > > except that I run the 4BSD scheduler.
> >
> > Possible culprits are r350374 and r350375, but I can't really see how.
> >
> 
> This started after the 6-Aug build (r350664). My prior build was r350292,
> so just before these two commits.
> 
> Can I try just reverting these two? Once I do, it will need to run for a
> while or do something to tie up a lot of memory before the error will
> recur. In normal use it is a matter of firefox increasing resident memory
> until there is not enough free memory to load the VM without swapping.
> (These days I often see the sum of all firefox process resident memory
> exceeding 3G after it's been up for a day or two. Still, not worse than
> chromium.)

Those commits can simply be reverted, but I am skeptical that they will
help.  You should also verify that these same conditions don't lead to
errors on your prior build, if you haven't already.