From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from john@localhost) by boreas.southchinaseas (8.9.3/8.9.3) id RAA00420 for ; Fri, 23 Jun 2000 17:08:15 +0100 Subject: Re: [RFC] RSS guarantees and limits References: <20000623005945.E9244@redhat.com> From: "John Fremlin" Date: 23 Jun 2000 17:08:14 +0100 In-Reply-To: Stephen Tweedie's message of "Fri, 23 Jun 2000 00:59:45 +0100" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mm@kvack.org Return-Path: To: linux-mm@kvack.org List-ID: Stephen Tweedie writes: [...] > The RSS bounds are *DYNAMIC*. If there is contention for memory --- > if lots of other processes want the memory that that emacs is > holding --- then absolutely you want to cut back on the emacs RSS. > If there is no competition, and emacs is the only active process, then > there is no need to prune its RSS. Yes, I agree with both parts. The second part is what I was trying to get across with the example because I thought that case was being ignored. I thought the part of the proposal was to control its RSS and give the surplus to the little processes so that when the admin tried to telnet in to kill it, inetd would be in memory and nicely responsive. You (Stephen) said earlier: > It is critically important that when under memory pressure, a > system administrator can still log in and kill any runaway > processes. [...] I took that to imply that inetd would have to be kept in memory. Sorry for the confusion caused. [...] -- http://altern.org/vii -- 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/