From owner-freebsd-hackers@freebsd.org Sat Apr 21 06:57:15 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D9F8FA7936 for ; Sat, 21 Apr 2018 06:57:15 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id C7EE78044E for ; Sat, 21 Apr 2018 06:57:14 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id w3L6vCrR015279 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 20 Apr 2018 23:57:13 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132] claimed to be yv.noip.me Subject: Re: Runaway processes freeze the system To: Freebsd hackers list References: From: Yuri Message-ID: Date: Fri, 20 Apr 2018 23:57:11 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US 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, 21 Apr 2018 06:57:15 -0000 On 04/20/18 12:17, Stefan Blachmann wrote: > Ideally rctl(8) should be the solution. > Actions can be defined to refuse to allocate more memory or kill > processes that demand too much memory. > > By turning off swap and restricting memory usage one can improve > performance by preventing the swapper making the system sluggish. > > However, rctl is only of limited use for desktop users, as Xorg fails > to start if vmemoryuse gets restricted (no matter how big the value). > So rctl(8) appears of practical use only for example for protecting > servers and embedded systems from crashing and damaging filesystems > because of user programs eating up too much memory. > > I advise you to experiment with it, as the rctl(8) documentation/man > page seems partly incorrect/misleading, for example regarding per-user > resource limiting. I am trying to understand what happens when both memory and swap are completely exhausted, and some process still tries to allocate more. This process calls mmap, but it can't succeed. There are only a few things that the kernel can do: 1. wait in a hope that some other process will return some memory soon 2. fail mmap 3. kill some process to free memory. It seems like the current behavior is to wait indefinitely. First one large offending process freezes. Then other, smaller processes that attempt to allocate some more memory also freeze, one by one, and the whole system becomes unusable. I am trying to understand why this behavior occurs, instead of options 2 or 3? Are there any relevant sysctl variables? Is this a conscious choice of behavior? Is there some malfunction involved, and this isn't the intended behavior? Yuri