From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 18 Jul 2002 15:00:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 18 Jul 2002 15:00:41 -0400 Received: from gateway-1237.mvista.com ([12.44.186.158]:27636 "EHLO hermes.mvista.com") by vger.kernel.org with ESMTP id ; Thu, 18 Jul 2002 15:00:40 -0400 Subject: Re: [PATCH] strict VM overcommit for stock 2.4 From: Robert Love To: root@chaos.analogic.com Cc: Szakacsits Szabolcs , linux-mm@kvack.org, linux-kernel@vger.kernel.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 18 Jul 2002 12:03:16 -0700 Message-Id: <1027018996.1116.136.camel@sinai> Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2002-07-18 at 11:56, Richard B. Johnson wrote: > What should have happened is each of the tasks need only about > 4k until they actually access something. Since they can't possibly > access everything at once, we need to fault in pages as needed, > not all at once. This is what 'overcomit' is, and it is necessary. Then do not enable strict overcommit, Dick. > If you have 'fixed' something so that no RAM ever has to be paged > you have a badly broken system. That is not the intention of Alan or I's work at all. Robert Love From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [PATCH] strict VM overcommit for stock 2.4 From: Robert Love In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: 18 Jul 2002 12:03:16 -0700 Message-Id: <1027018996.1116.136.camel@sinai> Mime-Version: 1.0 Sender: owner-linux-mm@kvack.org Return-Path: To: root@chaos.analogic.com Cc: Szakacsits Szabolcs , linux-mm@kvack.org, linux-kernel@vger.kernel.org List-ID: On Thu, 2002-07-18 at 11:56, Richard B. Johnson wrote: > What should have happened is each of the tasks need only about > 4k until they actually access something. Since they can't possibly > access everything at once, we need to fault in pages as needed, > not all at once. This is what 'overcomit' is, and it is necessary. Then do not enable strict overcommit, Dick. > If you have 'fixed' something so that no RAM ever has to be paged > you have a badly broken system. That is not the intention of Alan or I's work at all. Robert Love -- 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/