Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Dec 2023 19:25:55 -0600
From:      Mike Karels <mike@karels.net>
To:        freebsd-arch <freebsd-arch@freebsd.org>
Subject:   tmpfs is overly aggressive on memory usage
Message-ID:  <A8E7AA16-F034-4DAD-BB89-970B118002BC@karels.net>

next in thread | raw e-mail | index | archive | help
I have been looking at tmpfs and doing some experiments.  I had noticed
that tmpfs defaults to using a memory limit of "available amount of memory
(including main memory and swap space)", which seemed overly optimistic.
It isn't as bad as I first thought, as it is looking at current free memory
and swap space.  However, tests writing a file until something fails caused
all of swap space to be exhausted, and processes started getting killed.
In my test, this started with a large memory hog, but then killed root shells,
nfsd, etc.  This seems bad, and the system was screwed up enough that there
was no way to reboot it short of a reset.

One part of the problem was that with a default size, tmpfs enforced the limit
when creating a file but not when writing it.  I think this is an outright bug,
and I have a proposed fix in https://reviews.freebsd.org/D43010.  It has the
disadvantage that it can fail a write with ENOSPC due to a transient memory
load spike.  The memory limit is aggressive enough that the system is very close
to memory exhaustion, though, as well as swap space exhaustion (assuming there
is swap).

However, the limit is still high enough that continuous writes were likely
to cause processes to be killed and even system hangs.  I decided to try
increasing the memory reserve; currently tmpfs has a memory reserve threshold
of 4 MB.  I ended up with a default reserve based on a percentage of memory
plus swap, allowing 95% of available space to be used.  This works fairly
well in my tests, failing writes when the system is close to the edge and
paging fairly heavily, but without killing processes.  However, other
memory load was essentially constant; these changes cannot predict changes
in other memory demand, just react to the current situation.  This change
is in https://reviews.freebsd.org/D43011.

I'm interested in any feedback, in particular other approaches that might
be more general.

		Mike



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A8E7AA16-F034-4DAD-BB89-970B118002BC>