Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750727AbWBEVOS (ORCPT ); Sun, 5 Feb 2006 16:14:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750730AbWBEVOS (ORCPT ); Sun, 5 Feb 2006 16:14:18 -0500 Received: from linux01.gwdg.de ([134.76.13.21]:7555 "EHLO linux01.gwdg.de") by vger.kernel.org with ESMTP id S1750727AbWBEVOS (ORCPT ); Sun, 5 Feb 2006 16:14:18 -0500 Date: Sun, 5 Feb 2006 22:14:00 +0100 (MET) From: Jan Engelhardt To: Arjan van de Ven cc: Mark Lord , Ulrich Mueller , Herbert Poetzl , linux-kernel@vger.kernel.org, Jens Axboe , Linus Torvalds , Byron Stanoszek , Ingo Molnar , Andrew Morton Subject: Re: [PATCH ] VMSPLIT config options (with default config fixed) In-Reply-To: <1139153913.3131.42.camel@laptopd505.fenrus.org> Message-ID: References: <20060110132957.GA28666@elte.hu> <20060110133728.GB3389@suse.de> <20060110143931.GM3389@suse.de> <43C3E9C2.1000309@rtr.ca> <20060110173217.GU3389@suse.de> <43C3F0CA.10205@rtr.ca> <43C403BA.1050106@pobox.com> <43C40803.2000106@rtr.ca> <20060201222314.GA26081@MAIL.13thfloor.at> <43E3DB99.9020604@rtr.ca> <1139153913.3131.42.camel@laptopd505.fenrus.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1097 Lines: 29 >> > >> > Mmm.. bad idea. As much as I'd like the default to be 3GB_OPT, that would >> > be a big impact to userspace, and there's no point in breaking everyone's >> > machines when advanced users can just reconfig/recompile to get what they want. >> > >> What userspace programs do depend on it? > >there is a lot of userspace that assumes they can do 2Gb or even close >to 3Gb of memory allocations. Databases, java, basically anything with >threads. Sure for most of these its a configuration option to reduce >this, but that still doesn't mean it's a good idea to change from the >existing behavior... > Not to mention that these (almost(*)) fail anyway when you have less than 2 GB of RAM. (*) when finally writing to overcommitted memory Yuck. That sounds like they depend on 64G/64bit allocations on 4G/32bit machines. Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/