freebsd stable - Aug 2019 - Memory management changes after kernel update on 6-Aug

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?
> 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?
> 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.

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.)

Thanks, Mark, for the quick response.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman at gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683