From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 07:04:23 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 735A8401 for ; Thu, 28 Mar 2013 07:04:23 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by mx1.freebsd.org (Postfix) with ESMTP id 5690CE0 for ; Thu, 28 Mar 2013 07:04:23 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta07.emeryville.ca.mail.comcast.net with comcast id GuyY1l0071vN32cA7v4PPq; Thu, 28 Mar 2013 07:04:23 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id Gv4N1l0041t3BNj8iv4Ny2; Thu, 28 Mar 2013 07:04:22 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3208373A1C; Thu, 28 Mar 2013 00:04:22 -0700 (PDT) Date: Thu, 28 Mar 2013 00:04:22 -0700 From: Jeremy Chadwick To: Unga Subject: Re: FreeBSD 9.1 excessive memory allocations [SOLVED] Message-ID: <20130328070422.GA26584@icarus.home.lan> References: <1364322902.78474.YahooMailNeo@web161904.mail.bf1.yahoo.com> <1364393170.36972.49.camel@revolution.hippie.lan> <1364409226.37379.YahooMailNeo@web161906.mail.bf1.yahoo.com> <1364410923.36972.67.camel@revolution.hippie.lan> <1364449156.30979.YahooMailNeo@web161906.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1364449156.30979.YahooMailNeo@web161906.mail.bf1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364454263; bh=oWhQOTL521xAmP2bNkNz3WRf/9tyeuRVTBNMCZVdscM=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=jhDBuWh4tvWASlSeUHwtbA1j+JwsI+32ZFkHpifDL83rv9P2UKIGam+2ZwBPlEhjg pjMGir5vg5SCl4dFMBpxzC3SUK2yNI7XNJwxs2WqU3Sxvwpjjmu2e0QThla51q77Oc FCIKY3yNbMIPoWzXNB9KKZMGafWVDUJRdWbl8538sXXbpD0YjsLr1hf9+M5M/MiTKx AdS8cnOTp9QA3gHmS64jDrgaJFmUjmArXlY1fsx/ix74VmSQBHKOTCZiXa1V3+8fZ1 sSFAfe6bKKHa3cAycjwDJZtGvNT6uR1/XQR8Jzw0RGl/3u9+5EqTAGbaqiafCY+oWS e/t5OFG16V1/Q== Cc: "freebsd-stable@FreeBSD.org" 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: Thu, 28 Mar 2013 07:04:23 -0000 On Wed, Mar 27, 2013 at 10:39:16PM -0700, Unga wrote: > > I think you may be reading too much into the malloc manpage.? When it > > mentions the use of per-thread small-object caches to avoid locking it's > > talking about performance, not thread safety.? Allocations of all sizes > > are thread-safe, the library just assumes that huge allocations are rare > > enough that it doesn't use extra per-thread resources to avoid locking > > for them, it just uses locking for huge blocks. > > > > -- Ian > > Good to note all allocations are thread safe in FreeBSD. Is it by some > standard that malloc should be thread safe regardless the OS (BSDs, > Linux, Windows, Android, etc)? The Internet is sometimes a useful resource. http://stackoverflow.com/questions/855763/malloc-thread-safe http://stackoverflow.com/questions/987444/about-thread-safety-in-malloc-and-free http://msdn.microsoft.com/en-us/library/ms235505.aspx http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx On the BSDs, with gcc -pthread you should be fine. Don't ask me about Clang/LLVM. On Linux, glibc's routines are apparently thread-safe barring if the software was built with -DNO_THREADS (which seems very unlikely given the risks). Android is Linux. On Windows, assuming you're using CRT libraries, the routines are thread-safe. I get the impression the threaded library versions are also thread-safe for their *alloc equivalents. I believe HeapAlloc is thread-safe, and am pretty sure Global* is thread-safe (barring very very old Wine environments). Solaris's routines are also thread-safe, barring you're using standard malloc and not mtmalloc or ptmalloc or libumem (try searching the web for things like "Solaris mtmalloc" and read). All these OSes in some way or another have support for multi-threaded malloc implementations for increased performance (this is separate from locking/lock contention) where, AFAIK, you get to do the locking yourself. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |