[Bug 275436] tmpfs does not honor memory limits on writes

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275436

--- Comment #7 from Mike Karels <karels@freebsd.org> ---
(In reply to Konstantin Belousov from comment #6)

> VM (alomst) always ensures that there are several free pages.  More, it even
> typically manages to free several pages in reasonable time.

Except for when it doesn't, e.g. when swap is filling up.  It also may require
killing processes in that case.  Given that tmpfs is supposed to limit to
"available" memory, killing processes means that it has overshot.

> Now that I formulated this, I think that for tmpfs a reasonable approach would
> be something in line of per-process OOM: try the allocation, and return ENOSPC
> if it failed, with some criteria for restart.  You might look at vm/vm_fault.c
> vm_fault_allocate_oom().

I'm not sure, but tmpfs may go down that path if it can't get a page in
uiomove_object(). That may be desirable in case of transient memory shortage. I
don't know what happens if it fails though.  But when swap is getting short, it
seems better to fail before that point.

I really think the default limit for tmpfs is overly aggressive.  If it really
tries to take all of available memory + swap (less a small reserve, currently 4
MB), processes will be killed and the system is likely to require manual
intervention. In the case of a transient memory shortage, blocking for memory
is fine (and may be done already?).  I am now looking at a reserve that is
scaled on memory + swap space, e.g. allowing tmpfs to use 95%.  The percentage
is controlled by a sysctl.  This still includes a check for available space in
the write path.  (There is already a check in the create path.)  This seems to
work fairly well, based on limited test circumstances so far.

-- 
You are receiving this mail because:
You are the assignee for the bug.