From owner-freebsd-hackers@freebsd.org Fri Dec 8 09:23:54 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57780E9EAA8 for ; Fri, 8 Dec 2017 09:23:54 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 24A8E6A8BC for ; Fri, 8 Dec 2017 09:23:54 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 57C8C2603A1; Fri, 8 Dec 2017 10:23:48 +0100 (CET) Subject: Re: OOM problem? To: Larry McVoy , freebsd-hackers@freebsd.org References: <20171208011430.GA16016@mcvoy.com> From: Hans Petter Selasky Message-ID: <558cbad9-036a-edce-af57-4b78d197016f@selasky.org> Date: Fri, 8 Dec 2017 10:21:00 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171208011430.GA16016@mcvoy.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 09:23:54 -0000 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