Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Feb 2014 02:07:51 +0000
From:      "Gumpula, Suresh" <Suresh.Gumpula@netapp.com>
To:        John-Mark Gurney <jmg@funkthat.com>
Cc:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Ian Lepore <ian@freebsd.org>
Subject:   RE: malloc(9)  and its alignment
Message-ID:  <D29CB80EBA4DEA4D91181928AAF51538438F10CC@SACEXCMBX04-PRD.hq.netapp.com>
In-Reply-To: <20140212220705.GV34851@funkthat.com>
References:  <D29CB80EBA4DEA4D91181928AAF51538438EED0A@SACEXCMBX04-PRD.hq.netapp.com> <1392214788.1145.52.camel@revolution.hippie.lan> <D29CB80EBA4DEA4D91181928AAF51538438EF8DC@SACEXCMBX04-PRD.hq.netapp.com> <20140212220705.GV34851@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the explanation John.  How about porting ARM way of handling req=
uired alignment with creation of separate zones
And allocating with uma_zalloc(zone) for  AMD64 too  for bus_dmamem_alloc?

Thanks
Suresh


-----Original Message-----
From: John-Mark Gurney [mailto:jmg@funkthat.com]=20
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  think=
ing  why malloc(9) does not return bucket size aligned pointers.=20

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 51=
2, some cache lines will be more heavily used than others, reducing the eff=
ective size of the cache...

This is only one reason not aligning to size may be better...

--=20
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D29CB80EBA4DEA4D91181928AAF51538438F10CC>