Getting Memory Trace

[Tae Jun Ham]

Hello,

I am wondering if it is possible to obtain the multi-core memory trace (which has accessed address, access type (R/W), and accessed core) at a reasonable time.

If this is not supported yet, please let me know if you have any idea about the way to implement it. 

Thank you

-Tae Jun Ham

[Trevor E. Carlson]

Tae Jun Ham.

What are you looking to do with the memory trace? I ask this because it is fairly easy to write a Pintool [1] that will capture memory traces on a per-software-thread basis.  But, by using a Pin tool, you will only be able to see the per-thread traces without timing and coherency information. Depending on what you want to do, it could be fairly straight-forward to implement it in either Pin or Sniper.

Trevor

[1] http://pintool.org/

--
--
--
You received this message because you are subscribed to the Google
Groups "Sniper simulator" group.
To post to this group, send email to snip...@googlegroups.com
To unsubscribe from this group, send email to
snipersim+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/snipersim?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Sniper simulator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to snipersim+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Tae Jun Ham]

Hi, 

Thank you for your help. 

I think memory trace without accurate timing / coherence is fine but I want them to be ordered. 

So does that mean I can simply run pin tool on Sniper and get the memory trace for "simulated" architecture? 

Thank you

[Wim Heirman]

Hi,

You cannot attach another Pin tool to Sniper. But it's easy to add a
few lines of code to Sniper's memory model that write out all the
memory accesses as they are being simulated.
Core::initiateMemoryAccess (in sniper/common/core/core.cc) should be a
good place for this.

Regards,
Wim

[Paul Rosenfeld]

Are you looking for pre-cache or post-cache traces?

If you want post-cache traces, I have implemented a patch that I can send to you for doing collecting this information from the DRAM controller.

On that note, I wanted to ask the sniper team a question. The function I've hooked to get the memory trace is DramCntlr::runDramPerfModel in common/core/memory_subsystem/pr_l1_pr_l2_dram_directory_msi/dram_cntlr.cc

There's a parameter to this function  "SubsecondTime now"  however, when I print it out, I get all kinds of seemingly random numbers out of it (some are huge, some are tiny and they are certainly not monotonically increasing as you'd hope time would be). What does the 'now' argument represent in this function? 

Thanks,
Paul

[Wim Heirman]

Hi Paul,

This number is indeed the timestamp of the current request, in
femtoseconds. There are a few reasons why it could advance
non-monotonically:

- Before the region of interest (ROI), there are no core timing models
so simulated time does not advance. It does so in the memory models,
which is why you are seeing non-zero values at all, but the cores
reset time to zero for each new request. Depending on the path the
request took to reach your DRAM controller (a core close-by or through
a NoC), the value can in this case be up to some tens of nanoseconds
(which is in the order of 10^7 in femtoseconds).

- During detailed simulation, because Sniper is a multi-threaded
simulator with relaxed synchronization, each core maintains its own
timestamp. By having a barrier across simulated cores, by default
every 100 simulated nanoseconds, these times are mostly synchronized
-- but since each core will be making requests using its own local
timestamp you should expect to see time jump back and forth by up 100
ns.

- Finally, Sniper models memory requests instantaneously. This means
that when a core makes an access, the address is checked at all cache
levels and potentially goes to DRAM, and the latency of the completed
access is returned to the core. If the core models an out-of-order
processor, this core model may then issue new requests that have a
starting time that is earlier than the completion time of the previous
request.

For some more background on the last two points, also see [1].
Obviously these are two design choices that can affect accuracy, but
they do increase simulation speed significantly so -- if you are using
Sniper for the right type of research -- this is a trade-off we are
willing to make.

If you are seeing other variations that cannot be explained by any of
these points (i.e., variations inside of ROI that are larger than a
few hundred nanoseconds) do let us know as you may have found a bug
;-)

Regards,
Wim

[1] http://snipersim.org/w/Causality

[Ian Wang]

Hey Paul, could you please tell me how to capture the after-cache (last level cache) traces from Pin? is there any pin tool for that?

Thanks.

Ian

[fatemeh]

 
Paul,
Hi,

could you please send to me the patch that you have implemented for doing collecting that information from the DRAM controller.

thanks and regards
Fatemeh

[Matt Drummond]

Paul, or others,

Has the patch been made available somewhere?  If not, could you send it to me as well?

Thank you,

Matt

[fatemeh]

Hello,

I used the following command to run four application simultaneously.

./run-sniper --benchmarks=splash2-fft-test-1,splash2-fft-test-1,splash2-fft-test-1,splash2-fft-test-1 -c gainestown

and I added a printf command to common/core/memory_subsystem/pr_l1_pr_l2_dram_directory_msi/dram_cntlr.cc file to print core_id of each read or write request that missed in LLC. I mean that it prints core 0, core 1, core 2 or core 3.

I used the requester variable as core_id of each request. but it prints core 0 for all reads and writes.

Is it correct to consider the requester variable as core_id of read and write requests?

Thanks and Regards,

Fatemeh

[Wim Heirman]

Fatemeh,

In the default configuration (gainestown), four cores share an L3 cache. It is this L3 cache (which inherits the identifier of its first core) that makes the DRAM requests. You would need to make the LLC private per core to be able to distinguish their accesses at the DRAM controller.

Regards,

Wim

--

--
--
You received this message because you are subscribed to the Google
Groups "Sniper simulator" group.
To post to this group, send email to snip...@googlegroups.com
To unsubscribe from this group, send email to
snipersim+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/snipersim?hl=en

---
You received this message because you are subscribed to the Google Groups "Sniper simulator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to snipersim+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Lokesh Siddhu]

Hello Paul, or others,

Could you mail me the patch or a link to the patch?

Thanks
Lokesh Siddhu

[arup de]

Hi All,
    I am new to sniper simulator. I would like to use it to get the memory trace. The memory trace holds the informations about various read write request to memory and associated time stamp. Please let me know if you have any patch  to extract those information.

Thanks,
Arup

[Lokesh Siddhu]

Hello

See common/core/memory_subsystem/pr_l1_pr_l2_dram_directory_msi/dram_cntlr.cc
Each time there is read, getDataFromDram is called.
Each time there is write, putDataToDram is called.
Both functions have parameters for address - IntPtr address and timestamp - SubsecondTime now.

The above information should be enough to get a memory trace.

Thanks
Lokesh Siddhu

[Manu]

Hi,

I have another quick question regarding this thread - are the addresses virtual or physical? 

If they are virtual, is there a mechanism for getting physical addresses, or do I need to write a VA to PA mapper of my own.

Cheers,
Manu

[Wim Heirman]

Hi Manu,

All memory addresses that you see in the cache models are physical. There is a va2pa mapper (TraceThread::va2pa) that is used when simulating multiple processes but that is called before accesses are sent through the memory models.

Regards,

Wim

--

--
--
You received this message because you are subscribed to the Google
Groups "Sniper simulator" group.
To post to this group, send email to snip...@googlegroups.com
To unsubscribe from this group, send email to

snipersim+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/snipersim?hl=en

---
You received this message because you are subscribed to the Google Groups "Sniper simulator" group.

To unsubscribe from this group and stop receiving emails from it, send an email to snipersim+unsubscribe@googlegroups.com.

[Vibodh Nautiyal]

Hi Paul, 

Could you please send me the patch that you have implemented for collecting information from the DRAM controller. 

Best,

Vibodh