Messages in this thread | | | From | "Linda Walsh" <> | Subject | RE: Cache coherency... and locking | Date | Fri, 21 Jul 2000 09:01:11 -0700 |
| |
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/
| |