27 Feb
2025
27 Feb
'25
2:23 a.m.
Hello Anyone interested in this silliness , I am just recently trying
to reacquaint myself with this os . Which I had a decent passing knowledge of
at one time . Not any real OS level or driver coding , But was least decently
acquainted . Now on with the preliminaries ...
Any good software items to update on this ol'thing that give me a better chance
of completing this task , Greatly welcome .
I have folowed , ths article which is a copy from (imo) several places , tho
all of them are using a axp-Emulator .
<https://gist.github.com/jamesy0ung/eeac82997ebeae92873d1f2844a14ac3>
I am using (I'll admit) a REAL AlphaStation 200 (4/100) with 384MB main memory &
three disks all are U160's 2x4G+1x72G , OS is installed on the 72G(now) & has a
/home dir for users rather that the default location . See info & error during
make of gcc . Those numbers for the allocation & total have been exactly the
same accross many iterations of attempts in that exact file .
# sizer -v
HP Tru64 UNIX V5.1B (Rev. 2650); Sun Feb 23 19:43:32 AKST 2025
It is at patch level 008 .
and had successfully compiled & installed all the prerequisites shown in the
article mentioned above .
It Seems the OS doesn't know how to access the swap properly .
root@as200:/home/buildnfs/gcc-4.4.7# env
PATH=/usr/local/bin:/sbin:/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/dt/bin:~/bin:.
make
... many lines snipped ...
/home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/prev-gcc/xgcc
-B/home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/prev-gcc/
-B/usr/local/alpha-dec-osf5.1b/bin/ -c -g -$
cc1: out of memory allocating 135816 bytes after a total of 796519376 bytes
make[3]: *** [fold-const.o] Error 1
make[3]: Leaving directory `/home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/buildnfs/gcc-4.4.7'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/buildnfs/gcc-4.4.7'
make: *** [all] Error 2
# swapon -s
Swap partition /dev/disk/dsk2g:
Allocated space: 249774 pages (1.91GB)
In-use space: 1520 pages ( 0%)
Free space: 248254 pages ( 99%)
Swap partition /dev/disk/dsk1b:
Allocated space: 49152 pages (384MB)
In-use space: 1630 pages ( 3%)
Free space: 47522 pages ( 96%)
Swap partition /dev/disk/dsk0b:
Allocated space: 49152 pages (384MB)
In-use space: 1618 pages ( 3%)
Free space: 47534 pages ( 96%)
Total swap allocation:
Allocated space: 348078 pages (2.66GB)
In-use space: 4768 pages ( 1%)
Available space: 343310 pages ( 98%)
# hwmgr show scsi
SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST
HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH
-------------------------------------------------------------------------
42: 0 as200 cdrom none 0 1 cdrom0 [0/4/0]
43: 1 as200 disk none 2 1 dsk0 [1/0/0]
44: 2 as200 disk none 2 1 dsk1 [1/1/0]
45: 3 as200 disk none 2 1 dsk2 [1/2/0]
# hwmgr -view dev
HWID: Device Name Mfg Model Location
------------------------------------------------------------------------------
3: /dev/dmapi/dmapi
4: /dev/scp_scsi
5: /dev/kevm
29: /dev/disk/floppy0c 3.5in floppy fdi0-unit-0
42: /dev/disk/cdrom0c TOSHIBA DVD-ROM SD-M1401 bus-0-targ-4-lun-0
43: /dev/disk/dsk0c IBM DDRS-34560D bus-1-targ-0-lun-0
44: /dev/disk/dsk1c COMPAQ BD07286224 bus-1-targ-1-lun-0
45: /dev/disk/dsk2c COMPAQ ST34371W bus-1-targ-2-lun-0
46: /dev/random
47: /dev/urandom
Tia , JimL
--
+---------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network & System Engineer | 3237 Holden Road | Give me Linux |
| jiml(a)system-techniques.com | Fairbanks, AK. 99709 | only on AXP |
+---------------------------------------------------------------------+
27 Feb
27 Feb
6:52 a.m.
On 27/02/2025 3:23 am, babydr DBA James W. Laferriere wrote:
It Seems the OS doesn't know how to access the
swap properly .
Wild guess incoming...
My active experience on HP stuff ends with HP9000's and HPUX, but could
it be an ulimit settings perhaps?
The article doesn't seem to set anything to 'unlim' or similar.
Older UNIX versions tend to limit process sizes, open files and such
and especially compiling GCC and the like tends to munch address space...
So it may 'want' to page out, but is limited by the max process size
and can't malloc anymore.
Bye, Arno.
8:45 p.m.
Hello Arno , Arrigo & Kenneth ,
Arno Hit it on the head with the ulimit . After I had sent the missive
I again went looking for the original url that had successfully complied tthis
version of GCC & founfd it , & of course the one item missing from the other
copies is the 'ulimit -d unlimited' & checking to what it was set too .
Arrigo mentioned a known difficulty with paging on Tru64 systems ,
Which I had set as he suggested , tho still had the same out of memory .
Kenneth , I had gone thru the install putting on the LAST Known patch
to Tru64 before I started even setting up , But I am still not complete sure if
there might be another newer one floating out there somewhere .
THANK YOU All for your responses !-) I (after the above) started
another build & this time had it dumping all output (2>&1) to a file , This AM
(here in AK) , I did a grep for the offending file & low and behold it compiled
error free & is approriately archived . Now I have to await (Hopefully) for the
completion of the CC portion & THEN The C++ which according to WILL take a
considerable amount of time to complete , IF it does .
((*)beebe(a)math.utah.edu)
Thank You All agn , JimL
On Thu, 27 Feb 2025, Arno Griffioen via TUHS wrote:
On 27/02/2025 3:23 am, babydr DBA James W. Laferriere
wrote:
--
+---------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network & System Engineer | 3237 Holden Road | Give me Linux |
| jiml(a)system-techniques.com | Fairbanks, AK. 99709 | only on AXP |
+---------------------------------------------------------------------+
It Seems the OS doesn't know how to access
the swap properly .
Wild guess incoming...
My active experience on HP stuff ends with HP9000's and HPUX, but could
it be an ulimit settings perhaps?
The article doesn't seem to set anything to 'unlim' or similar.
Older UNIX versions tend to limit process sizes, open files and such
and especially compiling GCC and the like tends to munch address space...
So it may 'want' to page out, but is limited by the max process size
and can't malloc anymore.
Bye, Arno.
28 Feb
28 Feb
3:49 a.m.
Hello All , Just to tidy up this thread ,
VVVV LIne number in logfile .
2012:cc -c -g -DIN_GCC -DHAVE_CONFIG_H -I. -I. -I../.././gcc
-I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include
-I/usr/local/include -I/usr/local/include -I../.././gcc/../libdecnumber
-I../.././gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include
../.././gcc/fold-const.c -o fold-const.o
4640:/home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/prev-gcc/xgcc
-B/home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/prev-gcc/
-B/usr/local/alpha-dec-osf5.1b/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include
-I../.././gcc/../libcpp/include -I/usr/local/include -I/usr/local/include
-I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd
-I../libdecnumber -I/usr/local/include ../.././gcc/fold-const.c -o
fold-const.o
Successful build to this point NOW for the loonngggg Wait for the rest
of the story ;-) .
Hopefully tomorrow a completed build of GCC, c&c++ .
Thank you all again . JimL
On Thu, 27 Feb 2025, babydr DBA James W. Laferriere wrote:
Hello Arno , Arrigo & Kenneth ,
Arno Hit it on the head with the ulimit . After I had sent the
missive I again went looking for the original url that had successfully
complied tthis version of GCC & founfd it , & of course the one item missing
from the other copies is the 'ulimit -d unlimited' & checking to what it
was
set too .
Arrigo mentioned a known difficulty with paging on Tru64 systems ,
Which I had set as he suggested , tho still had the same out of memory .
Kenneth , I had gone thru the install putting on the LAST Known
patch to Tru64 before I started even setting up , But I am still not
complete sure if there might be another newer one floating out there
somewhere .
THANK YOU All for your responses !-) I (after the above) started
another build & this time had it dumping all output (2>&1) to a file , This
AM (here in AK) , I did a grep for the offending file & low and behold it
compiled error free & is approriately archived . Now I have to await
(Hopefully) for the completion of the CC portion & THEN The C++ which
according to WILL take a considerable amount of time to complete , IF it does
.
((*)beebe(a)math.utah.edu)
Thank You All agn , JimL
On Thu, 27 Feb 2025, Arno Griffioen via TUHS wrote:
--
+---------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network & System Engineer | 3237 Holden Road | Give me Linux |
| jiml(a)system-techniques.com | Fairbanks, AK. 99709 | only on AXP |
+---------------------------------------------------------------------+
On 27/02/2025 3:23 am, babydr DBA James W.
Laferriere wrote:
It Seems the OS doesn't know how to access
the swap properly .
Wild guess incoming...
My active experience on HP stuff ends with HP9000's and HPUX, but could
it be an ulimit settings perhaps?
The article doesn't seem to set anything to 'unlim' or similar.
Older UNIX versions tend to limit process sizes, open files and such
and especially compiling GCC and the like tends to munch address space...
So it may 'want' to page out, but is limited by the max process size
and can't malloc anymore.
Bye, Arno. 
27 Feb
27 Feb
7:43 a.m.
On 27 Feb 2025, at 03:28, babydr DBA James W. Laferriere <babydr(a)baby-dragons.com>
wrote:
cc1: out of memory allocating 135816 bytes after a
total of 796519376 bytes
That’s an “easy one”: you have to turn off the preallocation and run lazy memory
allocation.
“Digital UNIX has two paging modes, lazy and conservative. Conservative means that paging
space is allocated as memory is allocated, guaranteeing that there is always somewhere to
page to. This limits VM to the size of the paging partitions, but makes for a very robust
system. Lazy is more like what people are used to with Unix - paging space is allocated
when needed for paging out, you can run more jobs, but you're in big trouble when
everything fills up. By default, Digital UNIX comes up in the conservative mode. Removing
theswapdefaults file changes the system to lazy mode.”
Cheers,
Arrigo
(old OSF/1 hand since T1.0)
10:06 p.m.
Arrigo Triulzi wrote:
“Digital UNIX has two paging modes, lazy and
conservative. Conservative means that paging space is allocated as memory is allocated,
guaranteeing that there is always somewhere to page to. This limits VM to the size of the
paging partitions, but makes for a very robust system. Lazy is more like what people are
used to with Unix - paging space is allocated when needed for paging out, you can run more
jobs, but you're in big trouble when everything fills up.
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
10:55 p.m.
On Thu, Feb 27, 2025, 17:07 Phil Budne <phil(a)ultimate.com> wrote:
Arrigo Triulzi wrote:
Yes, this is the case for Ultrix, and I can imagine that it survived into
Tru64 (I don't have my Alphaserver up right now). You need to have disk
space allocated to swap for any memory that you want to map, regardless of
how much physical memory you have.
-Henry
“Digital UNIX has two paging modes, lazy and
conservative. Conservative
means that paging space is allocated as memory is
allocated, guaranteeing
that there is always somewhere to page to. This limits VM to the size of
the paging partitions, but makes for a very robust system. Lazy is more
like what people are used to with Unix - paging space is allocated when
needed for paging out, you can run more jobs, but you're in big trouble
when everything fills up.
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
28 Feb
28 Feb
5:08 a.m.
New subject: VM over-commit (and the OOM killers)
At Thu, 27 Feb 2025 17:55:49 -0500, Henry Bent <henry.r.bent(a)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(a)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.
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(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
6:12 a.m.
New subject: VM over-commit (and the OOM killers)
Random but related.
I've always called the OOM killer the Grim Memory Reaper; is that weird?
-uso.
6:55 a.m.
New subject: VM over-commit (and the OOM killers)
Steve Nickolas wrote:
I've always called the OOM killer the Grim Memory
Reaper; is that weird?
No, it's not weird. Elsewhere in computer history there was also the
"Grim File Reaper" (or often just "GFR"), which took care of moving
rarely used files from disk to tape storage. I think it's appropriate
to honor this usage.
3:03 p.m.
New subject: VM over-commit (and the OOM killers)
On 2/28/25 12:08 AM, Greg A. Woods wrote:
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).
I think this is one of the things macOS inherited from NeXT.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
3:32 p.m.
New subject: VM over-commit (and the OOM killers)
On Thu, Feb 27, 2025, 10:08 PM Greg A. Woods <woods(a)robohack.ca> wrote:
At Thu, 27 Feb 2025 17:55:49 -0500, Henry Bent
<henry.r.bent(a)gmail.com>
wrote:
Subject: [TUHS] Re: Having dickens of a time compiling gcc-4.4.7 on tru64 .
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
On Thu, Feb 27, 2025, 17:07 Phil Budne <phil(a)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.
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(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
3:57 p.m.
New subject: VM over-commit (and the OOM killers)
I’m probably a lost soul on this issue, but swap space is just a way to turn program bugs
into performance problems.
In HPC one says “real programs need real memory”.
At SiCortex we ran 972 node cluster machines without any swap space (4 or 8 GB per node)
and it worked fine. Of course we didn’t have any disks either, so we made a virtue of
necessity.
It is perfectly true that the OOM killer was feared and hated, but only because it
couldn’t identify the actual bad apple.
I realize this attitude only works when you (pretty much) dedicate a node to running a
single program at a time, but that is how most HPC systems of the time worked.
-L
4:04 p.m.
New subject: VM over-commit (and the OOM killers)
I’m probably a lost soul on this issue, but swap space
is just a way
to turn program bugs into performance problems.
You're hardly the only one. Some years ago, running Linux web and
database servers, I quit creating swap space. A runaway program would
turn the system into an infinite game of shuffle-the-pages well before
the OOM killer actually decided to kill something, and in that state,
one couldn't even reboot. This expanded the time window of "broken"
from tens of seconds, and perhaps a service restart, into tens of
minutes and a power button recovery. Every #$%^&* time.
De
4:12 p.m.
New subject: VM over-commit (and the OOM killers)
On Friday, February 28th, 2025 at 8:04 AM, Dennis Boone <drb(a)msu.edu> wrote:
I've read several bits of guidance lately suggesting avoiding swap due to the
increasing prevalence of solid-state memories. The assertion is that I/O heavy swapping,
especially if you get into a thrashing state, is liable to age current storage
technologies much more than it would have in the platter disk era. I've heard
contrary opinions that it isn't as large of a liability in reality. I haven't
settled on one or the other, I keep a swap file around on the microSD that runs my RPi,
but I've only needed to swapon, like OP, when compiling gcc.
- Matt G.
I’m probably a
lost soul on this issue, but swap space is just a way
to turn program bugs into performance problems.
You're hardly the only one. Some years ago, running Linux web and
database servers, I quit creating swap space. A runaway program would
turn the system into an infinite game of shuffle-the-pages well before
the OOM killer actually decided to kill something, and in that state,
one couldn't even reboot. This expanded the time window of "broken"
from tens of seconds, and perhaps a service restart, into tens of
minutes and a power button recovery. Every #$%^&* time.
De
4:20 p.m.
New subject: VM over-commit (and the OOM killers)
On Fri, Feb 28, 2025 at 9:12 AM segaloco via TUHS <tuhs(a)tuhs.org> wrote:
On Friday, February 28th, 2025 at 8:04 AM, Dennis
Boone <drb(a)msu.edu>
wrote:
I've read several bits of guidance lately suggesting avoiding swap due to
the increasing prevalence of solid-state memories. The assertion is that
I/O heavy swapping, especially if you get into a thrashing state, is liable
to age current storage technologies much more than it would have in the
platter disk era. I've heard contrary opinions that it isn't as large of a
liability in reality. I haven't settled on one or the other, I keep a swap
file around on the microSD that runs my RPi, but I've only needed to
swapon, like OP, when compiling gcc.
Swapping to flash can be fine. The days when a "spot" could be worn out are
20 years in the past. If you use it as a "shock absorber" to cope with
transient loads, there's no issues.
However a lot depends on which kind of flash you have, you might have
trouble if the load is constant. Today there's a wide range of flash
drives. Ranging from < .1DWPD drives (you can't write even 10% of the
drive's capacity in one day w/o wearing it out in the warranty period) to
3, 5 or 10 DWPD drives. 0.3 and 1.0 seem popular in the consumer / prosumer
/ low-end-datacenter space. Those can be a problem if you are constantly
swapping (but again are fine for coping with transients).
The MicroSD is likely to be closer to the .1-.3 DWPD (unless you bought an
expensive one).
Warner
I’m
probably a lost soul on this issue, but swap space is just a way
to turn program bugs into performance problems.
You're hardly the only one. Some years ago, running Linux web and
database servers, I quit creating swap space. A runaway program would
turn the system into an infinite game of shuffle-the-pages well before
the OOM killer actually decided to kill something, and in that state,
one couldn't even reboot. This expanded the time window of "broken"
from tens of seconds, and perhaps a service restart, into tens of
minutes and a power button recovery. Every #$%^&* time.
De
5:09 p.m.
New subject: VM over-commit (and the OOM killers)
I've read several bits of guidance lately
suggesting avoiding swap
due to the increasing prevalence of solid-state memories. The
assertion is that I/O heavy swapping, especially if you get into a
thrashing state, is liable to age current storage technologies much
more than it would have in the platter disk era.
I was told a few years ago by a smart person I respect that one of the
reasons Mac laptops were still so poorly endowed with RAM (iirc 8 GB
max) was because Apple was shipping SSD in them, so the performance hit
wasn't really noticeable. One hopes those were sturdy (DWPD) SSDs, but
barring the marketing decisions (removing ports people want), Apple's
hardware engineering is usually decent.
De
7:35 p.m.
New subject: VM over-commit (and the OOM killers)
At Fri, 28 Feb 2025 12:09:49 -0500, Dennis Boone <drb(a)msu.edu> wrote:
Subject: [TUHS] Re: VM over-commit (and the OOM killers)
I was told a few years ago by a smart person I respect that one of the
reasons Mac laptops were still so poorly endowed with RAM (iirc 8 GB
max) was because Apple was shipping SSD in them, so the performance hit
wasn't really noticeable. One hopes those were sturdy (DWPD) SSDs, but
barring the marketing decisions (removing ports people want), Apple's
hardware engineering is usually decent.
That's probably mostly true, but also misguided and ignorant of the
actual behaviour of RAM-starved systems. I suspect it was policy based
on memory prices at some time in the past, but seemingly hasn't been
re-evaluated for modern workloads more recently.
MacOS has long been OK at handling a little bit of paging, but seems to
get to the state of thrashing far sooner than one would expect it to. I
find Apple's default memory provisioning to be half as big as it should
be for the real-world uses most people encounter, especially these days
with the bloatware that is modern desktop software (especially browsers!)
On my BSD systems I always allocate lots of swap space (I try for at
least as much as I have RAM, if not more), but I get worried any time I
see any of it used. As Warner said, it's fine for transient loads, but
if a system starts paging during regular production loads then I have a
big problem.
--
Greg A. Woods <gwoods(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
8:18 p.m.
New subject: VM over-commit (and the OOM killers)
It appears that Greg A. Woods <tuhs(a)tuhs.org> said:
-=-=-=-=-=-
At Fri, 28 Feb 2025 12:09:49 -0500, Dennis Boone <drb(a)msu.edu> wrote:
Subject: [TUHS] Re: VM over-commit (and the OOM killers)
>
> I was told a few years ago by a smart person I respect that one of the
> reasons Mac laptops were still so poorly endowed with RAM (iirc 8 GB
> max) was because Apple was shipping SSD in them, ...
That's probably mostly true, but also misguided
and ignorant of the
actual behaviour of RAM-starved systems. I suspect it was policy based
on memory prices at some time in the past, but seemingly hasn't been
re-evaluated for modern workloads more recently.
Current Macbooks all start at 16GB, and the biggest Pro model can have
128GB and an 8TB SSD for the low low price of $7200.
I agree it's memory prices to make a balanced system. For a lot of
people who are not doing heavy computing 8GB is fine. If you're doing
a lot of compiling or ray-tracing, you need more computer.
R's,
John
8:53 p.m.
New subject: VM over-commit (and the OOM killers)
On 28 Feb 2025, at 20:36, Greg A. Woods <woods(a)robohack.ca> wrote:
That's probably mostly true, but also misguided
and ignorant of the
actual behaviour of RAM-starved systems. I suspect it was policy based
on memory prices at some time in the past, but seemingly hasn't been
re-evaluated for modern workloads more recently.
I strongly agree: as an old Unix hand hitting swap was something you wanted to avoid at
all cost, except for certain cases where swap use could be replaced by accurate use of
files to swap data in and out of RAM during programme execution because of the
predictability of data accesses. It was still bad programming but not as lethal as
thrashing.
The current macOS is a disappointment in that respect: on a 64GB machine when running the
Apple Virtualisation Framework for VMs (UTM and Parallels) I am surprised at how just a
couple of 8GB VMs can send the VMM into a frenzy.
My FreeBSD bhyve hosts with similar memory and VM load do not exhibit this behaviour at
all, despite ZFS ARC.
Arrigo
4:42 p.m.
New subject: VM over-commit (and the OOM killers)
The counterpoint to "just say no to swapping" is that sometimes you really,
really, want a job to proceed even if at a glacial pace.
Some years ago I had to do a Linux kernel build on a 1GB(maybe less?) MIPS
system, and even though it had oodles of swap space, the OOM killer kept
biting.
Turns out you have to tune "swappiness" in poorly documented ways to get
Linux to actually use virtual memory. I think the build took about a
week once it worked.
On Fri, Feb 28, 2025 at 8:04 AM Dennis Boone <drb(a)msu.edu> wrote:
I’m probably a
lost soul on this issue, but swap space is just a way
to turn program bugs into performance problems.
You're hardly the only one. Some years ago, running Linux web and
database servers, I quit creating swap space. A runaway program would
turn the system into an infinite game of shuffle-the-pages well before
the OOM killer actually decided to kill something, and in that state,
one couldn't even reboot. This expanded the time window of "broken"
from tens of seconds, and perhaps a service restart, into tens of
minutes and a power button recovery. Every #$%^&* time.
De
5:17 p.m.
New subject: VM over-commit (and the OOM killers)
In Feb 2013 I built the raspbian kernel on the original Raspi (512MB). Took about 10
hours. Don't recall if any swap was used but likely. Not sure how different was the
raspbian kernel at that time compared to the stock linux kernel (if there is such a
thing). I never wanted to repeat the build though!
In contrast the plan9 kernel build took a minute.
On Feb 28, 2025, at 8:42 AM, Tom Lyon
<pugs78(a)gmail.com> wrote:
The counterpoint to "just say no to swapping" is that sometimes you really,
really, want a job to proceed even if at a glacial pace.
Some years ago I had to do a Linux kernel build on a 1GB(maybe less?) MIPS system, and
even though it had oodles of swap space, the OOM killer kept biting.
Turns out you have to tune "swappiness" in poorly documented ways to get Linux
to actually use virtual memory. I think the build took about a week once it worked.
On Fri, Feb 28, 2025 at 8:04 AM Dennis Boone <drb(a)msu.edu
<mailto:drb@msu.edu>> wrote:
> > I’m probably a lost soul on this issue, but swap space is just a way
> > to turn program bugs into performance problems.
>
> You're hardly the only one. Some years ago, running Linux web and
> database servers, I quit creating swap space. A runaway program would
> turn the system into an infinite game of shuffle-the-pages well before
> the OOM killer actually decided to kill something, and in that state,
> one couldn't even reboot. This expanded the time window of "broken"
> from tens of seconds, and perhaps a service restart, into tens of
> minutes and a power button recovery. Every #$%^&* time.
>
> De
1
days inactive
2
days old
21 comments
16 participants
participants (16)
-
Arno Griffioen -
Arrigo Triulzi -
babydr DBA James W. Laferriere -
Bakul Shah -
Chet Ramey -
Dennis Boone -
Greg A. Woods -
Henry Bent -
John Levine -
Lars Brinkhoff -
Lawrence Stewart -
Phil Budne -
segaloco -
Steve Nickolas -
Tom Lyon -
Warner Losh