From owner-freebsd-hackers Tue Oct 22 18:47: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E78C37B401 for ; Tue, 22 Oct 2002 18:47:00 -0700 (PDT) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.135.138.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6981A43E42 for ; Tue, 22 Oct 2002 18:46:59 -0700 (PDT) (envelope-from fanf@chiark.greenend.org.uk) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 184Abp-0005ek-00 (Debian); Wed, 23 Oct 2002 02:46:57 +0100 To: tlambert2@mindspring.com From: Tony Finch Cc: hackers@freebsd.org Subject: Re: malloc In-Reply-To: <3DB5BB47.EFF55D5D@mindspring.com> References: <3DB5A07F.AA118FA6@mindspring.com> <20021022202533.A29425@chiark.greenend.org.uk> <3DB5AB73.E334629@mindspring.com> <20021022213917.B29425@chiark.greenend.org.uk> Message-Id: Date: Wed, 23 Oct 2002 02:46:57 +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > >The security comment had to do with the fact that zeroing occurs in >the kernel in the idle loop, and can account for a large latency in >the case of a big demand in user space. It's a philosophy issue that >led to the implementation, and it has a performance impact that's >higher in FreeBSD than in Linux, under some usage patterns. You said that Linux doesn't guarantee to zero pages handed from the system to userland, which is wrong. You've also mentioned the in- kernel page-zeroing strategy which is irrelevant when comparing different userland malloc implementations on the same OS. Hand-waving about the peanut gallery when I am trying to get you to be more specific about your vague assertions is not helpful. >The context of the current discussion is a FreeBSD admin with Linux >users bitching at him about core dumps in an overcommit case, where >he's hitting an administrative limit, and then trying to dereference >a pointer to a page that has an established mapping, but for which >there is no page available to act as backing store. I'm slightly perplexed about this: his program shouldn't have dumped core when hitting an administrative limit because it was correctly checking the return value from malloc(), and he's unlikely to be in an overcommit situation on a machine with 4GB of RAM when allocating only 800MB especially when it works with the administrative limit removed. Perhaps the core came from a different version of the program what didn't check for errors properly. Tony. -- f.a.n.finch http://dotat.at/ IRISH SEA: NORTHWEST BACKING WEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9. SQUALLY SHOWERS. GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message