Date: Mon, 04 Dec 2023 19:50:15 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 275436] tmpfs does not honor memory limits on writes Message-ID: <bug-275436-227-SGafDGBl6S@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-275436-227@https.bugs.freebsd.org/bugzilla/> References: <bug-275436-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275436 --- 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 e= ven > 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 requ= ire 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 E= NOSPC > if it failed, with some criteria for restart. You might look at vm/vm_fa= ult.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 shortag= e. 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 rea= lly tries to take all of available memory + swap (less a small reserve, current= ly 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 memo= ry 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 percent= age 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-275436-227-SGafDGBl6S>