From owner-freebsd-hackers Thu Dec 9 9:24:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from blackbox.csres.utexas.edu (blackbox.csres.utexas.edu [128.83.141.207]) by hub.freebsd.org (Postfix) with ESMTP id 52EB41564C for ; Thu, 9 Dec 1999 09:24:16 -0800 (PST) (envelope-from emery@cs.utexas.edu) Received: from cs.utexas.edu (localhost [127.0.0.1]) by blackbox.csres.utexas.edu (8.9.3/8.9.3) with ESMTP id LAA17253; Thu, 9 Dec 1999 11:24:13 -0600 Message-ID: <384FE5BD.8C0B4A88@cs.utexas.edu> Date: Thu, 09 Dec 1999 11:24:13 -0600 From: Emery Berger Organization: University of Texas at Austin X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Cc: Rayson Ho Subject: Re: Faster Malloc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: (regarding Hoard: ) > This allocator is pretty much what the Dynix allocator is, it wouldn't be > difficult to clean-room implement this with a BSD license. > > They should have given credit to Dynix or at least Uresh Vahalia > (discussed on page 390 of his book Unix Internals section 12.9). Hi all, The DYNIX kernel allocator was by McKenney and Slingwine, and I'll be citing them in a revised version of the paper. While there are a number of differences between my allocator (Hoard) and theirs, the most important are locality related. I'll just bring up one here: false sharing. Using the McKenney & Slingwine allocator (or the new Cilk allocator, discussed in my paper), a cache line can end up distributed across every CPU's free list and repeatedly re-used. This happens because freed blocks are placed back on a CPU's own freelist. This effect has been observed in practice and can dramatically worsen application performance. Hoard prevents this effect. Each superblock is owned by exactly one processor. When processor A free()'s a block from another CPU's superblock, it is put back in the superblock, and so will not be re-used by processor A's next malloc(). Regards, -- Emery -- Emery Berger | Parallel Programming emery@cs.utexas.edu | & Multiprogramming MP Groups | University of Texas at Austin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message