From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 23 Mar 2001 20:41:01 +0000 (GMT) From: Paul Jakma Subject: Re: [PATCH] Prevent OOM from killing init In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Szabolcs Szakacsits Cc: Alan Cox , Stephen Clouse , Guest section DW , Rik van Riel , Patrick O'Rourke , linux-mm@kvack.org, linux-kernel@vger.kernel.org List-ID: On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote: > About the "use resource limits!". Yes, this is one solution. The > *expensive* solution (admin time, worse resource utilization, etc). traditional user limits have worse resource utilisation? think what kind of utilisation a guaranteed allocation system would have. instead of 128MB, you'd need maybe a GB of RAM and many many GB of swap for most systems. some hopefully non-ranting points: - setting up limits on a RH system takes 1 minute by editing /etc/security/limits.conf. - Rik's current oom killer may not do a good job now, but it's impossible for it to do a /perfect/ job without implementing kernel/esp.c. - with limits set you will have: - /possible/ underutilisation on some workloads. - chance of hitting Rik's OOM killer reduced to almost nothing. no matter how good or bad Rik's killer is, i'd much rather set limits and just about /never/ have it invoked. more beancounting will make limits more useful (eg global?) and maybe dists can start setting up some kind of limits by default at install time based on the RAM installed and whether user selected server/workstation/etc.. install. Then hopefully we can be a little less concerned about how close Rik gets to the impossible task of implementing esp.c. > Szaka --paulj -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux.eu.org/Linux-MM/