Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 3 Nov 2000 15:27:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 3 Nov 2000 15:27:29 -0500 Received: from [213.129.28.90] ([213.129.28.90]:9991 "EHLO anor.exbit-technology.com") by vger.kernel.org with ESMTP id ; Fri, 3 Nov 2000 15:27:18 -0500 To: Andrea Arcangeli Cc: Linux-Kernel Subject: Re: Value of TASK_UNMAPPED_SIZE on 2.4 In-Reply-To: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: Kai Harrekilde-Petersen Date: 03 Nov 2000 21:27:07 +0100 In-Reply-To: Andrea Arcangeli's message of "Fri, 3 Nov 2000 19:38:34 GMT" Message-ID: <80snp8reck.fsf@orthanc.exbit-technology.com> Lines: 26 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Andrea Arcangeli writes: > On Fri, Nov 03, 2000 at 11:15:46AM -0800, Josue Emmanuel Amaro wrote: > > (page.h). This works out to be a value of 0x4000000. > ^ one more zero here > > Are there any negative side effects in defining TASK_UNMAPPED_SIZE to 0x1000000? > > I guess you mean 0x10000000. There's no risk in doing that. I also did another > patch that moves the kernel away and allows 3.5G per process on IA32 via plain > mmap or shmat, but it has the downside of reducing a lot the ZONE_NORMAL where > on IA32 buffercache and skb still lives. Is this available as a patch, or preferably as a compilation option to the standard kernel? The ASIC tools that we use wants all the memory they can grab, and the extra few hundred megs can sometimes be _very_ critical. On Solaris, Synopsys' Design Compiler can allocate 3.8Gig and we've hit that limit hard when working with toplevel netlists and SDF databases. Thanks in advance, Kai -- Kai Harrekilde-Petersen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/