Details about DRAM coherence directory
334 views
Skip to first unread message
Vignesh Balaji
Sep 6, 2017, 1:33:02 AM9/6/17
to Sniper simulator
Hi,
I have a few questions regarding the DRAM directory cache in Sniper:
1) Is my understanding of the implementation correct - The coherence directory is in the DRAM
(which keeps track of the sharers of the entire system memory). The directory cache is a separate
structure which exploits locality in coherence directory accessees. Finally, inter-socket coherence is enforced
by the DRAM directory and intra-socket coherence is enforced by the shared LLC (via snooping?)
2) If the above picture is true, then do the dram costs reported in dumpstats.py (dram-remote and dram-local for
multi-socket designs) include this overhead of accessing the coherence directory. Are these reported in td-access
which is used by llcstack.py?
3) Based on the discussion in thread link, it seems that the average LLC miss cost (uncore-totaltime) does not
account for miss-overlapping. My observations also corroborate this fact - uncore-totaltime > barrier-global.time.
Does sniper track LLC miss costs (particularly, coherence directory accesses) after accounting for miss-overlapping?
My use case is to identify the overhead of coherence (accessing the coherence directory, forwarding data requests
to owners, invalidating sharers, etc.) and plot them in the cycle stack. I think the cyclestack already identifies most
of the coherence overhead (through L1_S, L2_S, etc.) but not the latency of accessing dram directory. Any
pointers on tracking this would be appreciated.
Also, I would appreciate any resources that explain the coherence protocol implementation used in sniper. It looks
like the protocol implementation follows Section 8.6.1 of the "Primer on memory consistency and cache coherence"
Thanks,
Vignesh
I have a few questions regarding the DRAM directory cache in Sniper:
1) Is my understanding of the implementation correct - The coherence directory is in the DRAM
(which keeps track of the sharers of the entire system memory). The directory cache is a separate
structure which exploits locality in coherence directory accessees. Finally, inter-socket coherence is enforced
by the DRAM directory and intra-socket coherence is enforced by the shared LLC (via snooping?)
2) If the above picture is true, then do the dram costs reported in dumpstats.py (dram-remote and dram-local for
multi-socket designs) include this overhead of accessing the coherence directory. Are these reported in td-access
which is used by llcstack.py?
3) Based on the discussion in thread link, it seems that the average LLC miss cost (uncore-totaltime) does not
account for miss-overlapping. My observations also corroborate this fact - uncore-totaltime > barrier-global.time.
Does sniper track LLC miss costs (particularly, coherence directory accesses) after accounting for miss-overlapping?
My use case is to identify the overhead of coherence (accessing the coherence directory, forwarding data requests
to owners, invalidating sharers, etc.) and plot them in the cycle stack. I think the cyclestack already identifies most
of the coherence overhead (through L1_S, L2_S, etc.) but not the latency of accessing dram directory. Any
pointers on tracking this would be appreciated.
Also, I would appreciate any resources that explain the coherence protocol implementation used in sniper. It looks
like the protocol implementation follows Section 8.6.1 of the "Primer on memory consistency and cache coherence"
Thanks,
Vignesh
Bernard Nongpoh
Dec 4, 2018, 1:57:06 AM12/4/18
to Sniper simulator
Hi Vignesh,
I am working on the same line as yours. Any pointer to the directory implementation in sniper. Trying to match with the section 8.6.1 but not sure whether it follow the same.
Regards,
Bernard Nongpoh
Vignesh Balaji
Oct 30, 2019, 7:48:55 PM10/30/19
to Sniper simulator
Hi,
directory is either co-located with a NUCA cache slice or is at the DRAM. The fact that this structure is named "dram_directory" tripped my
understanding of where the structure is actually located.
Vignesh
Reply all
Reply to author
Forward
0 new messages