From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 12 14:19:54 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A302EE4 for ; Wed, 12 Feb 2014 14:19:54 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7585E178F for ; Wed, 12 Feb 2014 14:19:54 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WDafI-000MOg-Va; Wed, 12 Feb 2014 14:19:53 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s1CEJmSB074186; Wed, 12 Feb 2014 07:19:48 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19lyvIjqE1NKsgY05EYw7sD Subject: Re: malloc(9) and its alignment From: Ian Lepore To: "Gumpula, Suresh" In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Feb 2014 07:19:48 -0700 Message-ID: <1392214788.1145.52.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" 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: Wed, 12 Feb 2014 14:19:54 -0000 On Wed, 2014-02-12 at 02:02 +0000, Gumpula, Suresh wrote: > Hi, > It appears the malloc(9) returns 8 byte aligned ( UMA_ALIGN_PTR) pointers, but in bus_dmamem_alloc we might end up checking for greater alignment > if we take malloc(9) path instead contig_malloc. > Can someone please confirm if malloc(9) returns different alignment pointers ? > > bus_dmamem_alloc(bus_dma_tag_t dmat, void** vaddr, int flags, > bus_dmamap_t *mapp) > { > /* > * XXX: > * (dmat->alignment < dmat->maxsize) is just a quick hack; the exact > * alignment guarantees of malloc need to be nailed down, and the > * code below should be rewritten to take that into account. > * > * In the meantime, we'll warn the user if malloc gets it wrong. > */ > if ((dmat->maxsize <= PAGE_SIZE) && > (dmat->alignment < dmat->maxsize) && > dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem)) { > *vaddr = malloc(dmat->maxsize, M_DEVBUF, mflags); > } else { > > *vaddr = contigmalloc(dmat->maxsize, M_DEVBUF, mflags, > 0ul, dmat->lowaddr, dmat->alignment? dmat->alignment : 1ul, > dmat->boundary); > } > if (vtophys(*vaddr) & (dmat->alignment - 1)) { > NETAPP_MUTED_PRINTF("bus_dmamem_alloc failed to align memory properly.\n"); > > Regards, > Suresh In my experience, the effective malloc(9) alignment ends up being the same as MINALLOCSIZE, which is UMA_SMALLEST_UNIT, which is 16 bytes on a system with 4K pages. At $work we overrode MINALLOCSIZE to 32 to work around cache line alignment problems in busdma for ARM systems a few years ago. There is a newer set of busdma allocator routines available in kern/subr_busdma_bufalloc.c which are designed to give a platform more control over alignment of busdma buffers smaller than a page. An example of using them can be found in arm/busdma_machdep[-v6].c. As far as I know, they're only being used on ARM platforms right now. -- Ian