[TUHS] VM over-commit (and the OOM killers)

[Warner Losh]

On Thu, Feb 27, 2025, 10:08 PM Greg A. Woods <woods at robohack.ca> wrote:

> At Thu, 27 Feb 2025 17:55:49 -0500, Henry Bent <henry.r.bent at gmail.com>
> wrote:
> Subject: [TUHS] Re: Having dickens of a time compiling gcc-4.4.7 on tru64 .
> >
> > On Thu, Feb 27, 2025, 17:07 Phil Budne <phil at ultimate.com> wrote:
> >
> > > Arrigo Triulzi wrote:
> > >
> > > My recall is that 4.2BSD would only give you (writable) memory it
> > > could allocate swap space for.
> > >
> > > I think of the penchant for "overcommitting" memory
> > > (and the cold hand of the OOM killer) as Linuxisms
>
> I'm pretty sure over-commit in virtual memory systems is older than
> linux, and of course it's common in the BSDs now too.
>

I switched from early Linux to FreeBSD because Linux lacked overcommit at
the time (or it was so buggy you had to disable it). I thought this was a
4.4bsd thing, but FreeBSD's VM saw heavy work for big workloads right
away...

VMS 4 or 5 allowed it, with enough tuning.

Warner

Windows-NT did it, as did early AIX.  IBM'S VM does it, as do many other
> virtual machine supervisors.  Unix System V may even have done it.  I
> don't know where it originated, and I couldn't find a quick reference
> online just now to give a history of it, but likely someone here does.
>
> AIX also had an "OOM" killer (but I think it was the paging system
> itself, no a user-level process) -- which in early releases (the first
> version 3 on RS/6000 in 1989 or 1990) just tromped on the biggest
> process, which was usually the Xserver.  I seem to remember the system
> rebooting if X died too.  Even earlier (for the RT) IBM had invented
> SIGDANGER to warn of a pending OOM condition.  Big users of memory could
> catch SIGDANGER and know they had to release some memory if they could.
> I think catchers of SIGDANGER would avoid the early SIGKILLs too, but I
> don't believe the Xserver tried to catch SIGDANGER, at least not in
> early releases.
>
> Some systems, e.g. macOS (nee OS X) somewhat solved the problem by
> simply adding more swap space dynamically by creating files in the root
> filesystem (until the disk fills).
>
> --
>                                         Greg A. Woods <gwoods at acm.org>
>
> Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
> Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20250228/d567e356/attachment.htm>