From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 15 00:33:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43DE3AD2; Sat, 15 Feb 2014 00:33:52 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1866216FD; Sat, 15 Feb 2014 00:33:51 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s1F0XouW017563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Feb 2014 16:33:51 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s1F0XnNj017562; Fri, 14 Feb 2014 16:33:49 -0800 (PST) (envelope-from jmg) Date: Fri, 14 Feb 2014 16:33:49 -0800 From: John-Mark Gurney To: "Gumpula, Suresh" Subject: Re: malloc(9) and its alignment Message-ID: <20140215003349.GT34851@funkthat.com> Mail-Followup-To: "Gumpula, Suresh" , "freebsd-hackers@freebsd.org" , Ian Lepore References: <1392214788.1145.52.camel@revolution.hippie.lan> <20140212220705.GV34851@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 14 Feb 2014 16:33:51 -0800 (PST) Cc: "freebsd-hackers@freebsd.org" , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 00:33:52 -0000 Gumpula, Suresh wrote this message on Fri, Feb 14, 2014 at 02:07 +0000: > Thanks for the explanation John. How about porting ARM way of handling required alignment with creation of separate zones > And allocating with uma_zalloc(zone) for AMD64 too for bus_dmamem_alloc? It looks like the code in HEAD is different than the code you originally quoted, this is because HEAD added support for DMAR from Intel VT-d, the code is now in bounce_bus_dmamem_alloc in x86/x86/busdma_bounce.c, but it still has the same comment: 398 /* 399 * XXX: 400 * (dmat->alignment < dmat->maxsize) is just a quick hack; the exact 401 * alignment guarantees of malloc need to be nailed down, and the 402 * code below should be rewritten to take that into account. 403 * 404 * In the meantime, we'll warn the user if malloc gets it wrong. 405 */ Per porting arm's way of handling alignment, that makes sense... Though arm's way forces all allocations to be aligned to the size of a buffer, but I don't see a better way to handle it.. > -----Original Message----- > From: John-Mark Gurney [mailto:jmg@funkthat.com] > Sent: Wednesday, February 12, 2014 5:07 PM > To: Gumpula, Suresh > Cc: Ian Lepore; freebsd-hackers@freebsd.org > Subject: Re: malloc(9) and its alignment > > Gumpula, Suresh wrote this message on Wed, Feb 12, 2014 at 19:40 +0000: > > Thanks Ian for the reply. I will look at the ARM code, but I was thinking why malloc(9) does not return bucket size aligned pointers. > > Always returning bucket sizes aligned pointers may not be ideal for a cache.. say you have a buffer of 512 bytes, where often only the first > 128 bytes are used (but all 512 bytes may be)... If you always align at 512, some cache lines will be more heavily used than others, reducing the effective size of the cache... > > This is only one reason not aligning to size may be better... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."