From owner-freebsd-current@FreeBSD.ORG  Tue Nov 29 22:31:06 2005
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
X-Original-To: current@freebsd.org
Delivered-To: freebsd-current@FreeBSD.ORG
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 1921016A41F
	for <current@freebsd.org>; Tue, 29 Nov 2005 22:31:06 +0000 (GMT)
	(envelope-from jasone@canonware.com)
Received: from lh.synack.net (lh.synack.net [204.152.188.37])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 7B35D43D60
	for <current@freebsd.org>; Tue, 29 Nov 2005 22:30:59 +0000 (GMT)
	(envelope-from jasone@canonware.com)
Received: by lh.synack.net (Postfix, from userid 100)
	id B26805E48F5; Tue, 29 Nov 2005 14:30:59 -0800 (PST)
Received: from [192.168.168.203]
	(moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by lh.synack.net (Postfix) with ESMTP id DCFF55E4891;
	Tue, 29 Nov 2005 14:30:54 -0800 (PST)
In-Reply-To: <Pine.LNX.4.53.0511291357361.27754@regurgitate.ugcs.caltech.edu>
References: <B6653214-2181-4342-854D-323979D23EE8@canonware.com>
	<Pine.LNX.4.53.0511291121360.27754@regurgitate.ugcs.caltech.edu>
	<EB2C1DEE-C0BA-4E9B-95C6-A44AE45A06ED@canonware.com>
	<Pine.LNX.4.53.0511291357361.27754@regurgitate.ugcs.caltech.edu>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5724A68F-E731-4F1F-A908-A7875AB93B3D@canonware.com>
Content-Transfer-Encoding: 7bit
From: Jason Evans <jasone@canonware.com>
Date: Tue, 29 Nov 2005 14:27:26 -0800
To: Jon Dama <jd@ugcs.caltech.edu>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net
X-Spam-Level: *
X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL,
	RCVD_IN_SORBS_DUL autolearn=no version=3.0.4
Cc: current@freebsd.org
Subject: Re: New libc malloc patch
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Nov 2005 22:31:06 -0000

On Nov 29, 2005, at 2:21 PM, Jon Dama wrote:
> Let me take a closer look at what you are doing with regards to
> cache-lines.  You seem to be implying that you are only taking care in
> regards to how you malloc within a given page?

You are correct that I am only taking care about allocations within a  
given page.

> I have a suspicion that it might just be better to dump the problem  
> on to
> the application in the sense that no malloc should ever be less
> than the size of one cache line.  Perhaps this is what you are doing?

I am only worrying about cache line alignment for malloc's internal  
data structures.  It's up to the application to do this for its  
allocations, if necessary (doing so for all allocations would induce  
unacceptable internal fragmentation).  This implementation provides  
posix_memalign(3), which makes it much less painful for the  
application to do so.

Jason