From owner-freebsd-hackers@freebsd.org Sat Dec 9 00:29:02 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 51850E93313 for ; Sat, 9 Dec 2017 00:29:02 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 27E416AB26 for ; Sat, 9 Dec 2017 00:29:02 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id vB90T3eL029952 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 9 Dec 2017 00:29:04 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id vB90SpIb058586 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Dec 2017 16:28:53 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Fri, 8 Dec 2017 16:28:46 -0800 (PST) From: Don Lewis Subject: Re: OOM problem? To: Larry McVoy cc: Konstantin Belousov , freebsd-hackers@freebsd.org In-Reply-To: <20171208150121.GH16028@mcvoy.com> Message-ID: References: <20171208011430.GA16016@mcvoy.com> <20171208101543.GC2272@kib.kiev.ua> <20171208150121.GH16028@mcvoy.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE 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: Sat, 09 Dec 2017 00:29:02 -0000 On 8 Dec, Larry McVoy wrote: > On Fri, Dec 08, 2017 at 12:15:43PM +0200, Konstantin Belousov wrote: >> A process waiting for a page in the fault handler must receive the page >> to get out of the handler, even if the system is in OOM. > > I may be confusing you because this is not the normal page fault on a file > code path (at least I think it is not). The process is indeed faulting > in pages but they are pages that were allocated via whatever malloc calls > these days (in SunOS it mmapped /dev/zero, before that it was sbrk(2), > I dunno what FreeBSD does, I couldn't find malloc in src/lib, I see that > it's jemalloc but /usr/src/lib/libc/stdlib/jemalloc has no files?) /usr/src/contrib/jemalloc