On Fri, 21 Jul 2000, Linda Walsh wrote:
> No -- I meant *just* reading. A process will need to read it's audit mask
> at every audit point. The audit mask would rarely be audited.
>
> If I'm just looking at the X86 architecture the MESI protocol used on
> Intel Buses would seem to indicate that no locking is needed. If CPUB
> has a more up-to-date copy in it's cache than what is in memory (i.e. it has
> modified the cache line but not yet copied it to memory, It should
> respond to CPU-A with the value as well as updating memory and the
> state of that cache line goes into 'Shared' mode. If it starts
> out as 'Shared' on both processors (both have been doing reads), and
> one writes to it, the writing processor is suppose to send out an
> Invalidate message so other caches know to flush it from their
> cache. This is all Intel stuff which by the book, should work.
You're not guaranteed that it'll happen instantly though. CPU-B might have
speculatively read the mask ahead of time. If you need strict causality
(and maybe you don't?), you need a lock.
> Note that in no case am I doing a 'read-modify-write'. Reads and
> writes are stricly LOAD or STORE. Now it would be convenient to
> have the audit mask structure (32 bytes) aligned directly on a
> cache boundary for optimal performance. Is there a way to guarantee
> that on X86? Does the -malign=x on the command line do that?
If you're doing dynamic allocation of your structures, the SLAB allocator
will put them on cache boundaries. -malign only deals with compile time
alignment, and primarily affects the alignment of structure members.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:18 EST