Date: Fri, 8 Dec 2017 10:21:00 +0100 From: Hans Petter Selasky <hps@selasky.org> To: Larry McVoy <lm@mcvoy.com>, freebsd-hackers@freebsd.org Subject: Re: OOM problem? Message-ID: <558cbad9-036a-edce-af57-4b78d197016f@selasky.org> In-Reply-To: <20171208011430.GA16016@mcvoy.com> References: <20171208011430.GA16016@mcvoy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/08/17 02:14, Larry McVoy wrote: > B) Sleep with PCATCH, if that doesn't work, loop sleeping for a period, > wake up and see if you are signaled. I'm rusty enough that I don't > remember if msleep() with PCATCH will catch signals or not (I don't > remember a msleep(), that might be a BSD thing and not a SunOS thing). > But whatever, either it catches signals or you replace that sleep with > a loop that sleeps for a second or so, wakes up and looks to see if it's > been signaled and if so dies, else goes back to sleep waiting for pageout > and/or OOM to free some mem. Hi, How will you handle kernel memory allocations with M_WAITOK, that are too big, because it is assumed that such allocations will always return non-NULL? When designing the USB stack in FreeBSD, it was important that memory was always pre-allocated, so that regular operation did not do malloc and free. Other systems I've seen simply panic and reboot when critical functions cannot get memory. Computing the exact size which needs to be pre-allocated puts a bit more logic into the software, but is worth it when the system runs out of memory. I see it strange that sshd cannot accept a connection requiring 64K of memory perhaps while another process has allocated Gigs of RAM, like in the example Larry pulled up. The same should be the case for disk space. Let applications like syslogd reserve some space in the file-system to write important logs. You might argue that's what we have partitions for as the simplest solution, so maybe memory should be partitioned aswell? --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?558cbad9-036a-edce-af57-4b78d197016f>