At Thu, 27 Feb 2025 17:55:49 -0500, Henry Bent <henry.r.bent@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@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@acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca>