Date: Thu, 07 Dec 2023 18:42:24 +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-XryLtcjcs2@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 #9 from Mike Karels <karels@freebsd.org> --- (In reply to Konstantin Belousov from comment #8) > Proposals to limit max tmpfs page uses to some percentage of the total of > memory and swap would not work. My proof-of-concept does not use total memory + swap. Instead, it computes= a reserve which is (100 - memlimit%) * (free memory + swap) at time of tmpfs_init(). This seems to work out reasonably in my test cases so far. I need to try with mapped files too. I'll attach my current patch. > There is simply no reasonable answer to question 'how to limit tmpfs phys= ical > memory consumption' without knowing the system load pattern. There is no perfect solution, that is true. But when memory + swap is low enough, allowing tmpfs to proceed makes bad things happen, like killing processes and hanging the system. Backing off a little makes things better= in at least some cases, which seems worthwhile to me. And tmpfs can report a failure (ENOSPC) without being killed, unlike processes touching memory. Y= es, a compile may fail, etc, but at least that is related to the shortage. It seems bad if writes to /tmp by an unprivileged user cause root or other important processes to be killed. --=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-XryLtcjcs2>