From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 23:50:37 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E7D06D07; Sun, 24 Feb 2013 23:50:37 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id BDDF7E91; Sun, 24 Feb 2013 23:50:37 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.6/8.14.6) with ESMTP id r1ONoYa3090743; Sun, 24 Feb 2013 17:50:35 -0600 (CST) (envelope-from stephen@missouri.edu) Message-ID: <512AA74A.4060708@missouri.edu> Date: Sun, 24 Feb 2013 17:50:34 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ian Lepore Subject: Re: svn - but smaller? References: <1359380582-6256705.77592125.fr0SDgrYH000991@rs149.luxsci.com> <20130224031509.GA47838@icarus.home.lan> <20130224041638.GA51493@icarus.home.lan> <20130224063110.GA53348@icarus.home.lan> <1361726397.16937.4.camel@revolution.hippie.lan> <20130224212436.GA13670@icarus.home.lan> <1361749413.16937.16.camel@revolution.hippie.lan> In-Reply-To: <1361749413.16937.16.camel@revolution.hippie.lan> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , Michael Ross , freebsd-stable@FreeBSD.org, John Mehr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 23:50:38 -0000 On 02/24/2013 05:43 PM, Ian Lepore wrote: > On Sun, 2013-02-24 at 13:24 -0800, Jeremy Chadwick wrote: >> On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote: >>> On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote: >>>> >>>> Also, John, please consider using malloc(3) instead of heap-allocated >>>> buffers like file_buffer[6][] (196608 bytes) and command[] (32769 >>>> bytes). I'm referring to this: >>> >>> Why? I absolutely do not understand why people are always objecting to >>> large stack-allocated arrays in userland code (sometimes with the >>> definition of "large" being as small as 2k for some folks). >> >> This is incredibly off-topic, but I'll bite. >> >> I should not have said "heap-allocated", I was actually referring to >> statically-allocated. >> >> The issues as I see them: >> >> 1. Such buffers exist during the entire program's lifetime even if they >> aren't actively used/needed by the program. With malloc(3) and friends, >> you're allocating memory dynamically, and you can free(3) when done with >> it, rather than just having a gigantic portion of memory allocated >> sitting around potentially doing nothing. >> >> 2. If the length of the buffer exceeds the amount of stack space >> available at the time, the program will run but the behaviour is unknown >> (I know that on FreeBSD if it exceeds "stacksize" per resource limits, >> the program segfaults at runtime). With malloc and friends you can >> gracefully handle allocation failures. >> >> 3. Statically-allocated buffers can't grow; meaning what you've >> requested size-wise is all you get. Compare this to something that's >> dynamic -- think a linked list containing pointers to malloc'd memory, >> which can even be realloc(3)'d if needed. >> >> The definition of what's "too large" is up to the individual and the >> limits of the underlying application. For some people, sure, anything >> larger than 2048 might warrant use of malloc. I tend to use malloc for >> anything larger than 4096. That "magic number" comes from some piece of >> information I was told long ago about what size pages malloc internally >> uses, but looking at the IMPLEMENTATION NOTES section in malloc(3) it >> appears to be a lot more complex than that. >> >> If you want me to break down #1 for you with some real-world output and >> a very small C program, showing you the effects on RES/RSS and SIZE/VIRT >> of static vs. dynamic allocation, just ask. >> > > Actually, after seeing that the userland limit for an unpriveleged user > on freebsd is a mere 64k, I'd say the only valid reason to not allocate > big things on the stack is because freebsd has completely broken > defaults. I see no reason why there should even be a distinction > between stack size and memory use limits in general. Pages are pages, > it really doesn't matter what part of your virtual address space they > live in. I think that the stacksize and datasize cannot together add up to more than 4G, or maybe it is only 2G, at least on a 32 bit machine. This is because (I think) they compete for virtual memory address space. I guess this wasn't a problem in the old days, when 4G of RAM was unthinkable. Also, as I said in another thread, I think Linux doesn't make this distinction. So at least someone else out there agrees with you.