From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 19 Jul 2002 09:30:32 +0200 (MEST) From: Szakacsits Szabolcs Subject: Re: [PATCH] strict VM overcommit for stock 2.4 In-Reply-To: <1027019414.1085.143.camel@sinai> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Robert Love Cc: root@chaos.analogic.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org List-ID: On 18 Jul 2002, Robert Love wrote: > Btw, without this it is possible to OOM any machine. OOM is a > by-product of allowing overcommit and poor accounting (and perhaps > poor software/users), not an incorrectly configured machine. Very well said, now I try to explain again what's missing from the patch: livelock is a by-product of allowing strict VM overcommit and poor accounting (and perhaps poor software/users), not an incorrectly configured machine. So where is the solution for "poor accounting (and perhaps poor software/users), not an incorrectly configured machine" users? These are part of life and please don't claim all your work was perfect at first shoot and automatically adapted in all changing environments whitout ever touching it again on a general purpose system. Even if it would be true, not everybody supergenius. So which one is better? OOM killer that considers root owned processes to make his decision or strict VM overcommit that doesn't distinguish root and non-root users and potentially will livelock [if you don't have some custom solution, like "trigger OOM handler through sysrq" patch posted here a year ago]. For embedded systems the later, for general purpose systems the first is better in average however this is not linux-embedded and later on people using Linux for general purpose could get the impression strict VM overcommit is useful for them and potentially would end up in a worse situation than without it (see my example sent, default kernel OOM killed the bad process, with your patch reset the box). *However* distinguishing root and non-root users also in strict VM overcommit would make a significant difference for general purpose systems, this was always my point. Can you see the non-orthogonality now? Szaka -- 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-mm.org/