Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Jun 2009 00:35:36 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Marcel Moolenaar <xcllnt@mac.com>
Cc:        kmacy@freebsd.org, marius@freebsd.org, FreeBSD Tinderbox <tinderbox@freebsd.org>, sparc64@freebsd.org, Eygene Ryabinkin <rea-fbsd@codelabs.ru>, current@freebsd.org
Subject:   Re: [head tinderbox] failure on sparc64/sun4v
Message-ID:  <alpine.BSF.2.00.0906040034350.74158@fledge.watson.org>
In-Reply-To: <15550775-6B8A-414E-A579-8B518D62E06E@mac.com>
References:  <20090602222445.2F6017302F@freebsd-current.sentex.ca> <mqQn8SFFPOY77oNsI7n1tk5O7LE@10Ilc7MfiXA2JVIRVQpZfk7cTQ4> <rPuoszoUcXlrNmrZFDbbbNJuZzs@XX1fo6zQUfC4h0jjRC6IBz3oNH4> <alpine.BSF.2.00.0906032104100.74158@fledge.watson.org> <15550775-6B8A-414E-A579-8B518D62E06E@mac.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Wed, 3 Jun 2009, Marcel Moolenaar wrote:

>> Is there a reason not just to use __aligned(64) or the like on the first 
>> entry of the MD PCPU structure for sun4v to avoid future MI pcpu changes 
>> from causing similar discomfort for the MD pcpu parts?  Also, do we know 
>> why these alignment/sizing requirements exist for struct pcpu on sun4v but 
>> not other platforms?  If this is about packing pcpu structures into 
>> properly aligned cache lines, again __aligned() might be the right approach 
>> to take...
>
> Adding __aligned(xx) doesn't make it aligned. For example, malloc(3) only 
> aligns at 16-byte boundaries, so any user-space structure that has 
> __aligned(x>16) must manually make sure that this is actually the case by 
> over-allocating and then adjusting the pointer to an x>16 aligned address. 
> Likewise for the kernel, though it's easier in the kernel to get something 
> that's page-aligned... FYI,

I wan't sure if that was the problem that caused the alignment code in this 
case.  However, I agree that malloc(9)'s lack of alignment support is a 
problem, and one that should be pretty easy to resolve by simply putting a bit 
of over-allocation code in malloc(9), and adding a malloc_aligned(9) 
variation, or perhaps just an M_CACHEALIGN flag.

Robert N M Watson
Computer Laboratory
University of Cambridge



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