Re: separating out memory checks from INVARIANTS
- From: Jeff Roberson <jroberson@xxxxxxxxxxxxxx>
- Date: Sun, 16 Mar 2008 12:33:11 -1000 (HST)
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
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
- References:
- separating out memory checks from INVARIANTS
- From: Kip Macy
- Re: separating out memory checks from INVARIANTS
- From: Jeff Roberson
- Re: separating out memory checks from INVARIANTS
- From: Kip Macy
- Re: separating out memory checks from INVARIANTS
- From: Jeff Roberson
- Re: separating out memory checks from INVARIANTS
- From: Bruce Evans
- separating out memory checks from INVARIANTS
- Prev by Date: Re: separating out memory checks from INVARIANTS
- Next by Date: HWPMC changes: sparse CPU numbering and hot plug preliminaries
- Previous by thread: Re: separating out memory checks from INVARIANTS
- Next by thread: HWPMC changes: sparse CPU numbering and hot plug preliminaries
- Index(es):
Relevant Pages
|
|
