RE: Cache coherency... and locking

From: Linda Walsh (law@sgi.com)
Date: Fri Jul 21 2000 - 11:01:11 EST


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.

My question is, is this guaranteed on all processors Linux runs on.
Has Linux been written with this assumption -- that cache management
has been done totally in HW and needs no SW support. Is it true
for Sparc? MIPS? IA64? Alpha? Etc.

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?

thanks,
-linda

--
Linda A Walsh                    | Trust Technology, Core Linux, SGI
law@sgi.com                      | Voice: (650) 933-5338                        

> and I assume "looking" means not just reads but potentially writes. > > I am sorry if this is already answered or if you figured it out yourself > (haven't looked at all of your thread) but I would recommend reading the > Chapter 7 of volume III of Intel PIII manuals: > > http://developer.intel.com/design/pentiumii/manuals/243192.htm > > or at least section 7.1.1 which says that the following basic memory > operations will always be carried out atomically: > > 1. reading/writing a byte > > 2. reading/writing a word aligned on a 16-bit boundary > > 3. reading/writing a doubleword aligned on a 32-bit boundary. > > additionally, on P6 only: > > 4. reading/writing a quadword aligned on a 64bit boundary > > 5. 16-bit access to uncached memory that fit within a 32-bit data bus > > 6. 16/32/64-bit access to cached memory that fit within a 32-byte cache > line > > This has practical implications in coding kernel code. For example a > little module I wrote in the past called timetravel (for Linux y2k > testing) updates some entries in sys_call_table[] which is declared using > ENTRY() macro in arch/i386/kernel/entry.S. If you look at ENTRY() you will > find that it is aligned well-enough for such updates to be guaranteed to > be atomic. > > Hope this helps. > > Regards, > Tigran > >

- 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:15 EST