freebsd stable - Jun 2018 - lightly loaded system eats swap space

Hi,

On Mon, 18 Jun 2018 13:27:23 +0100
tech-lists <tech-lists at zyxst.net> wrote:
> On 18/06/2018 09:08, Erich Dollansky wrote:
> > 
> > On Sun, 17 Jun 2018 23:19:02 +0100
> > tech-lists <tech-lists at zyxst.net> wrote:
> >   
> >> freebsd-11-stable r333874, ZFS raidz1-0 (3x4TB disks), 128GB RAM,
> >> Swap: 4096M Total, 3502M Used, 594M Free, 85% Inuse  
> > 
> > this might not be related but I noticed that your swap space is
> > small compared to RAM size. I noticed on a much smaller Raspberry
> > Pi, that it runs into trouble when there is no swap even there is
> > enough RAM available. Is it easily possible for you to add some GB
> > of swap space and let the machine run then?
> > 
> > How much swap do the other machines have?  
> 
> Yes, the machine with the problem uses the default 4GB swap. That's
> all the swap it has. The machine without issue has a swapfile
> installed on a SSD in addition to the default 4GB swap.
> 
> problematic machine:
> Device          512-blocks     Used    Avail Capacity
> /dev/ada0p3        8388608     3.3G     714M    83%
> 
> machine without a problem, it has swapfile installed:
> Device          512-blocks     Used    Avail Capacity
> /dev/ada0s1b       8262248     1.7G     2.2G    44%
> /dev/md0          65536000     1.9G      29G     6%
> Total             73798248     3.7G      32G    10%
> 
> I added the swapfile a long time ago on this machine due to the same
> issue.
so, the same effect as on a small Raspberry.

It seems that you also use a memory disk for swap. Mine is backed by a
file via NFS.
> 
> But my problem isn't so much an out of swapspace problem; all this
> is, is a symptom. My problem is "why is it swapping out at all on a
> 128GB system and why is what's swapped out not being swapped back in
> again".
> 
I wondered even on the small Raspberry about this. The Raspberries come
with 1GB of RAM. Running just a compilation should never be the problem
but sometimes it is.

A very long time ago - and not on FreeBSD but maybe on a real BSD - I
worked with a system that swapped pages out just to bring it back as
one contiguous block. This made a difference those days. I do not know
if the code made it out of the university I was working at. I just
imagine now that the code made it out and is still in use with the
opposite effect.

Erich

Am 19.06.18 um 03:48 schrieb Erich Dollansky:
> A very long time ago - and not on FreeBSD but maybe on a real BSD - I
> worked with a system that swapped pages out just to bring it back as
> one contiguous block. This made a difference those days. I do not know
> if the code made it out of the university I was working at. I just
> imagine now that the code made it out and is still in use with the
> opposite effect.
If this was on a VAX, then it was due to a short-coming of the
MMU of the VAX, which used one linear array (in system virtual
memory) to hold physical addresses of user pages of all programs.
Each user program had 2 slices in this array (1 growing up, 1
growing down for the stack) and whenever a program allocated a
new page, this slice needed to grow. That leads to fragmentation
(same a problem as with realloc() for an ever growing array), and
when there was no contiguous free space in the array for a grown
slice, then all process where swapped out (resulting in this whole
page table array being cleared and thus without fragmentation,
since swapped-out processes needed no space in this array).

This was a solution that worked without the table walk used in
todays VM systems. System pages were mapped by a linear page table
in physical memory, while user programs used the above described
linear page table in system virtual memory.

Nothing of the above applies to any other architecture than the
VAX and thus the swap-out of all user processes serves no purpose
on any other system. It was an implementation detail of the VAX
VM code, not a BSD Unix feature.

Regards, STefan