separating out memory checks from INVARIANTS

[Jeff Roberson]

On Mon, 17 Mar 2008, Bruce Evans wrote:

> On Sat, 15 Mar 2008, Jeff Roberson wrote:
>
>> On Sat, 15 Mar 2008, Kip Macy wrote:
>>> Would it make it possible to do memory allocation without holding a
>>> lock in the M_NOWAIT case?
>> 
>> Yes, when I originally wrote the code it didn't require a lock because I 
>> relied on byte writes being atomic.  However, we had platforms for which 
>> that wasn't true. (alpha).  It may be that it's safe not to lock even now 
>> on x86/amd64.  I don't know the specifics of the memory architectures on 
>> powerpc, arm, mips, etc. though.
>
> sparc64 only supports atomic ops on sizes 32 and 64 bits.  I think it
> and not alpha was responsible for eliminating use of 8 and 16 bit
> atomic ops in MI code.
>
> My version of atomic.h for i386 only supports atomic ops on size 32.
> 8 and 16 bit atomic ops are not usable in MI code and are or were not
> used in i386 MD code, so they are just interface bloat.

It actually doesn't require atomics, just a write memory barrier and the 
ability to write a single byte without affecting surrounding bytes.  The 
'owner' of the piece of memory sets its status in the array in the slab 
header.  The setting marks the memory as allocated.  You only have to have 
the write memory barrier to prevent one cpu from allocating and another 
from freeing the same piece of memory before the store to the slab 
header becomes visible.  That race is probably impossible given how small 
store buffers really usually are.

The real problem is that you can't write a single byte on earlier alphas. 
You would load 32bit, set the byte you were interested in, and store 
32bit.  On later alphas and other more reasonable machines if you write a 
byte the cache hardware essentially does that with a cache line, but using 
the coherency protocol to ensure that only that byte is written.

Jeff

>
> Bruce
>