From owner-freebsd-stable@FreeBSD.ORG Sat Dec 18 22:34:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93830106564A for ; Sat, 18 Dec 2010 22:34:51 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from fep28.mx.upcmail.net (fep28.mx.upcmail.net [62.179.121.48]) by mx1.freebsd.org (Postfix) with ESMTP id 0B4A78FC0C for ; Sat, 18 Dec 2010 22:34:50 +0000 (UTC) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep15-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20101218221752.TTI1633.viefep15-int.chello.at@edge01.upcmail.net>; Sat, 18 Dec 2010 23:17:52 +0100 Received: from pinky ([213.46.23.80]) by edge01.upcmail.net with edge id kmHq1f00z1jgp3H01mHrze; Sat, 18 Dec 2010 23:17:52 +0100 X-SourceIP: 213.46.23.80 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org, mamalos@eng.auth.gr References: <201012180947.oBI9lMoU092383@lurza.secnetix.de> <4D0CA06A.2080603@eng.auth.gr> Date: Sat, 18 Dec 2010 23:17:52 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <4D0CA06A.2080603@eng.auth.gr> User-Agent: Opera Mail/11.00 (Win32) X-Cloudmark-Analysis: v=1.1 cv=JvXQbuMnWGQeb488dJ7w43Du7THgE+O7ieb9U20/rjk= c=1 sm=0 a=ibccumBnqR4A:10 a=bgpUlknNv7MA:10 a=IkcTkHD0fZMA:10 a=OTpCH1uB5A2NhoDKScIA:9 a=UPwGookIBHp8xoehJbIA:7 a=Fmv0QQmSyubh4KiFr7uznZlh834A:4 a=QEXdDO2ut3YA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: Subject: Re: vm.swap_reserved toooooo large? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 22:34:51 -0000 On Sat, 18 Dec 2010 12:52:10 +0100, George Mamalakis wrote: > Oliver, > > I am sending you this email outside the list, because I think that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That didn't work out as you intended. :-) > enough emails have been sent regarding my message. > Now to your statements: > > On 18/12/2010 11:47 πμ, Oliver Fromme wrote: >> George Mamalakis wrote: >> > Oliver, thanx for your comments. I know it is difficult to choose >> which >> > process to kill and how to be "fair" during such a killing >> procedure. >> > Nevertheless, I would assume that all non-root processes would have >> > higher priority to get killed, and that root's processes would get >> > killed last. >> >> The owner of the process is not taken into consideration, >> because the "run-away" process causing the memory shortage >> may as well be a root-owned process. In such a situation, >> if root processes were exempt from killing, the system >> would deadlock and require a hard reboot. Killing the >> root-owned process is the lesser of two evils. >> > As I explained in one of my previous emails, I expected that root > processes would have *lower priority* than non-root processes; I never > implied that root processes shouldn't get killed, it would be irrational > to say so. >> As I already explained, there is a process flag that root- >> owned processes can set for themselves, preventing the >> kernel from killing them in low-memory situations. See >> the description of the MADV_PROTECT flag in the madvise(2) >> manual page. For example, cron(8) and sshd(8) make use of >> this, so they will not be killed. This is a better way >> than simply excluding all root processes. >> >> > I understand your comments completely, but I was just so >> > surprised when I realized how easy it was for me to kill root >> processes >> > on my system. >> >> Only because you didn't configure resource limits. ;-) >> >> When you're the only user on a machine, such as a desktop >> box, this is usually not a big deal. But in all other >> cases it's strongly recommended to set resource limits, >> in particular for shell users and for server processes. >> >> Without any resource limits, a normal user can starve the >> system and take it down. This is an old and well-known >> problem for all UNIX systems (and most non-UNIX systems, >> too, I guess). You certainly didn't discover any new >> problem. >> >> If you're concerned, configure resource limits. Period. >> > As I stated in my first message (if I recall correctly), all this > happened because I didn't configure my rlimits (it's my laptop). Of > course I am aware of resource limits, and I configure them on most of > the servers I administer for the last 12 years (I've seen my vmstat > showing 500+ processes in blocked-by-io state, and the system wouldn't > hang..:)). I never implied to have discovered anything new, and > especially something regarding resource limits. All my enthusiasm was > caused firstly due to fbsd's memory allocation algorithm (I never knew > the system would assume that it could allocate 500+GB of memory, and the > replies on this issue where very enlightening for me), and secondly due > to fbsd's algorithm on process killing when memory has been starved. > Certainly, I was not surprised by the fact that my system was out of > memory...exceeding my system's memory limits was my experiment in the > first place! > > Anyway, thanx again for your answer and all your pointers (MADV_PROTECT, > etc), and I think there is no need to get angry about my emails. As I > initially stated, my questions where rhetorical, and no answers where > needed. I trusted that there should be a good reason behind this > behavior...Some of you answered on the list and I just replied with my > opinion. Nothing more, nothing less. > > Have a nice day and kind regards, > > mamalos