[Bug 275436] tmpfs does not honor memory limits on writes
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 275436] tmpfs does not honor memory limits on writes"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 04 Dec 2023 19:50:15 UTC
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.