10

I was reading about the MESI snooping cache coherence protocol, which I guess is the protocol that is used in modern multicore x86 processors (please correct me if I'm wrong). Now that article says this at one place.

A cache that holds a line in the Modified state must snoop (intercept) all attempted reads (from all of the other caches in the system) of the corresponding main memory location and insert the data that it holds. This is typically done by forcing the read to back off (i.e. retry later), then writing the data to main memory and changing the cache line to the Shared state.

Now what I don't understand is why the data needs to be written in the main memory. Cant the cache coherence just keeps the content in the caches synchronized without going to the memory (unless the cache line is truly evicted ofcourse)? I mean if one core is constantly reading and the other constantly writing, why not keep the data in the cache memory, and keep updating the data in the cache. Why incur the performance of writing back to the main memory?

In other words, can't the cores reading the data, directly read from the cache of the writing core and modify their cache accordingly?

Massimiliano
  • 16,770
  • 10
  • 69
  • 112
pythonic
  • 20,589
  • 43
  • 136
  • 219

5 Answers5

7

Now what I don't understand is why the data needs to be written in the main memory. Cant the cache coherence just keeps the content in the caches synchronized without going to the memory (unless the cache line is truly evicted ofcourse)?

This does happen.

I have on my laptop an iCore 5 which looks like this;

   M
   N
   S
  L3U
L2U L2U
L1D L1D
L1I L1I
 P   P
L L L L

M = Main memory
N = NUMA node
S = Socket
L3U = Level 3 Unified
L2U = Level 2 Unified
L1D = Level 1 Data
L1I = Level 1 Instruction
P = Processor
L = Logical core

When two logical cores are operating on the same data, they don't move out to main memory; they exchange over the L1 and L2 caches. Likewise, when cores in the two processors are working, they exchange data over the L3 cache. Main memory isn't used unless eviction occurs.

But a simpler CPU could indeed be less clever about things.

3

The MESI protocol doesn't allow more than one caches to keep the same cache line in a modified state. So, if one cache line is modified and wants to be read from other processor´s cache, then it must be first written to main memory and then read, so that both processor´s caches now share that line (shared state)

Win32
  • 1,109
  • 10
  • 12
2

Because caches typically aren't able to write directly into each other (as this would take more bandwidth).

Oliver Charlesworth
  • 267,707
  • 33
  • 569
  • 680
1

what I don't understand is why the data needs to be written in the main memory

Let's processor A has that modified line. Now processor B is trying to read that same cache (modified by A) line from main memory. Since the content in the main memory is invalid now (because A modified the content), A's snooping the any other read attempts for that line. So in order to allow processor B (and others) to read that line, A has to write it back to main memory.

I mean if one core is constantly reading and the other constantly writing,

why not keep the data in the cache memory, and keep updating the data in the cache.

You are right and this is what usually done. But here, that's not the case. Someone else (processor B in our example) is trying to read. So A has to write it back and make the cache line status to shared because both A and B are sharing the cache line now.

P.P
  • 117,907
  • 20
  • 175
  • 238
  • What I meant by not writing to the memory was that can't we do such that the cache coherence mechanism reads data from the cache of the writing core and convey it to those reading it. Is it necessary to first write in memory and then read it from there. Can't the reading cores directly read from the cache of the writing core? – pythonic Apr 07 '12 at 21:03
  • 1
    A modified line can be kept by a processor only as long as it's the only processor that has this copy (MESI). What you are saying can't done, because it's more expensive. Suppose, both of A & B share that line and B got it directly from the cache line of A and some one else, say C, needs that line for a write, then both A & B will have keep snooping that line. As the shared copies grows, then it will have greater impact on performance due to the snooping done by all the 'shared' processors. That's why this is not done. – P.P Apr 07 '12 at 21:16
  • Moreover, MESI uses write-back cache to reduce the writes back to main memory whenever possible. – P.P Apr 07 '12 at 21:20
1

So actually I don't think the reading cache has to go to main memory. In MESI, when a processor request a block modified by one of it's peers, it issue a read miss on the bus (or any interconnect medium), which is broadcasted to every processor.

The processor which hold the block in the "Modified" state catch the call, and issue a copy back on the bus - holding the block ID and the value - while changing it's own copy state to "shared". This copy back is received by the requesting processor, which will write the block in it's local cache and tag it as "shared".

It depends upon the implementation if the copy back issued by the owning processor goes to main memory, or not.

edit: note that the MOESI protocol add a "Owned" state that is very similar to "Shared", and allows a processor holding a copy of a block, in owned state, to copy back the value on the bus if it catches a broadcasted write/read miss for this block.

Bacon
  • 1,814
  • 3
  • 21
  • 36