gem5-users@gem5.org

The gem5 Users mailing list

View all threads

Different latencies

IS
Inderjit singh
Wed, May 11, 2022 4:38 PM
  1. What is the difference between data/tag/response latency?
  2. How can I add write latency (for NVM caches) in gem5, any patch?

Inderjit Singh

1. What is the difference between data/tag/response latency? 2. How can I add write latency (for NVM caches) in gem5, any patch? Inderjit Singh
IS
Inderjit singh
Mon, May 1, 2023 3:33 AM

Any ideas.

Inderjit Singh

On Wed, May 11, 2022 at 10:08 PM Inderjit singh <
inderjitsingh.davu@gmail.com> wrote:

  1. What is the difference between data/tag/response latency?
  2. How can I add write latency (for NVM caches) in gem5, any patch?

Inderjit Singh

Any ideas. Inderjit Singh On Wed, May 11, 2022 at 10:08 PM Inderjit singh < inderjitsingh.davu@gmail.com> wrote: > 1. What is the difference between data/tag/response latency? > 2. How can I add write latency (for NVM caches) in gem5, any patch? > > > Inderjit Singh > >
EM
Eliot Moss
Mon, May 1, 2023 11:46 AM

On 4/30/2023 11:33 PM, Inderjit singh via gem5-users wrote:

Any ideas.
Inderjit Singh

On Wed, May 11, 2022 at 10:08 PM Inderjit singh <inderjitsingh.davu@gmail.com
mailto:inderjitsingh.davu@gmail.com> wrote:

 1. What is the difference between data/tag/response latency?
 2. How can I add write latency (for NVM caches) in gem5, any patch?

The tag part of a cache records addresses and access/state bits, typically the
Valid bit (does this entry contain valid information - if not, the entry
should be ignored), Dirty (does the data differ from caches farther away or
the main memory), Shared (are there other copies of this line/block in other
caches), etc.

A cache first takes the address in the request (typically a read or write) and
sees if that addresses occurs is a valid entry in the cache.  The amount of
time to do this is the TAG latency.

The DATA latency is the additional time to supply (or update) the data if the
tag matches (a cache hit).

I believe the RESPONSE latency is how long it takes a cache to pass through a
response coming from beyond itself.

As for your question about write latency in NVM caches, I find the question a
little bit ambiguous.  I assume you mean volatile caches that cache
information coming from NVM.  DATA latency would be the write latency into
such a cache.  If you're talking about the internal buffers of an NVM, there
are a slew of parameters in the NVM interface (which combines all the
buffering, etc., with the actual data array).  See NVMInterface.py, but also
MemInterface.py.  To set such parameters on the command line, you have to do
it for each controller.

This bash code might give you a sense of a way to do it using a script:

MEMORY parameters

export GEM5_MEMTYPE=${GEM5_MEMTYPE:-NVM_2400_1x64}
export MEM_CHANNELS=${MEM_CHANNELS:-8}
export GEM5_XPARAMS="${GEM5_XPARAMS} --mem-channels=${MEM_CHANNELS}"
export TOTAL_MEM_SIZE_MB=${TOTAL_MEM_SIZE_MB:-512}

tREAD and tWRITE are guesses ...

Other values adjusted for 2666 MHz (vs 1200MHz in default gem5)

export MEM_TCK=${MEM_TCK:-0.357ns}
export MEM_TREAD=${MEM_TREAD:-125ns}
export MEM_TWRITE=${MEM_TWRITE:-180ns}
export MEM_TSEND=${MEM_TSEND:-6.28ns}
export MEM_TBURST=${MEM_TBURST:-1.528ns}
export MEM_TWTR=${MEM_TWTR:-0.357ns}
export MEM_TRTW=${MEM_TRTW:-0.357ns}
export MEM_TCS=${MEM_TCS:-0.714ns}
export MEM_DEVICE_SIZE=${MEM_DEVICE_SIZE:=$((TOTAL_MEM_SIZE_MB / MEM_CHANNELS))MB}

for (( i=0 ; i < $MEM_CHANNELS ; ++i )) ; do
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tCK='${MEM_TCK}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tREAD='${MEM_TREAD}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tWRITE='${MEM_TWRITE}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tSEND='${MEM_TSEND}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tBURST='${MEM_TBURST}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tWTR='${MEM_TWTR}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tRTW='${MEM_TRTW}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tCS='${MEM_TCS}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param
system.mem_ctrls[$i].dram.device_size='${MEM_DEVICE_SIZE}'"
done

This is designed to allow things like MEM_TCK to be set before running this
piece of script, but otherwise to supply the default value 0.357ns (for
example).  Once all the above is done, the command line itself must include
${GEM5_XPARAMS} to expand out all of the above.  Also, I know its confusing,
but in an NVM only system, the NVM controllers have the name "dram" even
though that are of NVM type!

HTH - Eliot Moss

On 4/30/2023 11:33 PM, Inderjit singh via gem5-users wrote: > Any ideas. > Inderjit Singh > > On Wed, May 11, 2022 at 10:08 PM Inderjit singh <inderjitsingh.davu@gmail.com > <mailto:inderjitsingh.davu@gmail.com>> wrote: > > 1. What is the difference between data/tag/response latency? > 2. How can I add write latency (for NVM caches) in gem5, any patch? The tag part of a cache records addresses and access/state bits, typically the Valid bit (does this entry contain valid information - if not, the entry should be ignored), Dirty (does the data differ from caches farther away or the main memory), Shared (are there other copies of this line/block in other caches), etc. A cache first takes the address in the request (typically a read or write) and sees if that addresses occurs is a valid entry in the cache. The amount of time to do this is the TAG latency. The DATA latency is the additional time to supply (or update) the data if the tag matches (a cache hit). I believe the RESPONSE latency is how long it takes a cache to pass through a response coming from beyond itself. As for your question about write latency in NVM caches, I find the question a little bit ambiguous. I assume you mean volatile caches that cache information coming from NVM. DATA latency would be the write latency into such a cache. If you're talking about the internal buffers of an NVM, there are a slew of parameters in the NVM interface (which combines all the buffering, etc., with the actual data array). See NVMInterface.py, but also MemInterface.py. To set such parameters on the command line, you have to do it for each controller. This bash code might give you a sense of a way to do it using a script: # MEMORY parameters export GEM5_MEMTYPE=${GEM5_MEMTYPE:-NVM_2400_1x64} export MEM_CHANNELS=${MEM_CHANNELS:-8} export GEM5_XPARAMS="${GEM5_XPARAMS} --mem-channels=${MEM_CHANNELS}" export TOTAL_MEM_SIZE_MB=${TOTAL_MEM_SIZE_MB:-512} ## tREAD and tWRITE are guesses ... ## Other values adjusted for 2666 MHz (vs 1200MHz in default gem5) export MEM_TCK=${MEM_TCK:-0.357ns} export MEM_TREAD=${MEM_TREAD:-125ns} export MEM_TWRITE=${MEM_TWRITE:-180ns} export MEM_TSEND=${MEM_TSEND:-6.28ns} export MEM_TBURST=${MEM_TBURST:-1.528ns} export MEM_TWTR=${MEM_TWTR:-0.357ns} export MEM_TRTW=${MEM_TRTW:-0.357ns} export MEM_TCS=${MEM_TCS:-0.714ns} export MEM_DEVICE_SIZE=${MEM_DEVICE_SIZE:=$((TOTAL_MEM_SIZE_MB / MEM_CHANNELS))MB} for (( i=0 ; i < $MEM_CHANNELS ; ++i )) ; do export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tCK=\'${MEM_TCK}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tREAD=\'${MEM_TREAD}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tWRITE=\'${MEM_TWRITE}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tSEND=\'${MEM_TSEND}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tBURST=\'${MEM_TBURST}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tWTR=\'${MEM_TWTR}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tRTW=\'${MEM_TRTW}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tCS=\'${MEM_TCS}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.device_size=\'${MEM_DEVICE_SIZE}\'" done This is designed to allow things like MEM_TCK to be set before running this piece of script, but otherwise to supply the default value 0.357ns (for example). Once all the above is done, the command line itself must include ${GEM5_XPARAMS} to expand out all of the above. Also, I know its confusing, but in an NVM only system, the NVM controllers have the name "dram" even though that are of NVM type! HTH - Eliot Moss
SF
Shen, Fangjia
Tue, May 2, 2023 5:01 PM

Regarding the data latency, I think it depends on whether the cache is sequential access (access cache tags, then data) or parallel access (access tags and data at the same time - common optimization for the L1 cache).  See the code for BaseCache::calculateAccessLatency. If sequentialAccess==true,  the sum of tag latency and data latency is used, otherwise the greater of tag latency and data latency.

Regards,
Fangjia


From: Eliot Moss via gem5-users gem5-users@gem5.org
Sent: Monday, May 1, 2023 7:46
To: The gem5 Users mailing list gem5-users@gem5.org
Cc: Eliot Moss moss@cs.umass.edu
Subject: [gem5-users] Re: Different latencies

---- External Email: Use caution with attachments, links, or sharing data ----

On 4/30/2023 11:33 PM, Inderjit singh via gem5-users wrote:

Any ideas.
Inderjit Singh

On Wed, May 11, 2022 at 10:08 PM Inderjit singh <inderjitsingh.davu@gmail.com
mailto:inderjitsingh.davu@gmail.com> wrote:

 1. What is the difference between data/tag/response latency?
 2. How can I add write latency (for NVM caches) in gem5, any patch?

The tag part of a cache records addresses and access/state bits, typically the
Valid bit (does this entry contain valid information - if not, the entry
should be ignored), Dirty (does the data differ from caches farther away or
the main memory), Shared (are there other copies of this line/block in other
caches), etc.

A cache first takes the address in the request (typically a read or write) and
sees if that addresses occurs is a valid entry in the cache.  The amount of
time to do this is the TAG latency.

The DATA latency is the additional time to supply (or update) the data if the
tag matches (a cache hit).

I believe the RESPONSE latency is how long it takes a cache to pass through a
response coming from beyond itself.

As for your question about write latency in NVM caches, I find the question a
little bit ambiguous.  I assume you mean volatile caches that cache
information coming from NVM.  DATA latency would be the write latency into
such a cache.  If you're talking about the internal buffers of an NVM, there
are a slew of parameters in the NVM interface (which combines all the
buffering, etc., with the actual data array).  See NVMInterface.py, but also
MemInterface.py.  To set such parameters on the command line, you have to do
it for each controller.

This bash code might give you a sense of a way to do it using a script:

MEMORY parameters

export GEM5_MEMTYPE=${GEM5_MEMTYPE:-NVM_2400_1x64}
export MEM_CHANNELS=${MEM_CHANNELS:-8}
export GEM5_XPARAMS="${GEM5_XPARAMS} --mem-channels=${MEM_CHANNELS}"
export TOTAL_MEM_SIZE_MB=${TOTAL_MEM_SIZE_MB:-512}

tREAD and tWRITE are guesses ...

Other values adjusted for 2666 MHz (vs 1200MHz in default gem5)

export MEM_TCK=${MEM_TCK:-0.357ns}
export MEM_TREAD=${MEM_TREAD:-125ns}
export MEM_TWRITE=${MEM_TWRITE:-180ns}
export MEM_TSEND=${MEM_TSEND:-6.28ns}
export MEM_TBURST=${MEM_TBURST:-1.528ns}
export MEM_TWTR=${MEM_TWTR:-0.357ns}
export MEM_TRTW=${MEM_TRTW:-0.357ns}
export MEM_TCS=${MEM_TCS:-0.714ns}
export MEM_DEVICE_SIZE=${MEM_DEVICE_SIZE:=$((TOTAL_MEM_SIZE_MB / MEM_CHANNELS))MB}

for (( i=0 ; i < $MEM_CHANNELS ; ++i )) ; do
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tCK='${MEM_TCK}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tREAD='${MEM_TREAD}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tWRITE='${MEM_TWRITE}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tSEND='${MEM_TSEND}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tBURST='${MEM_TBURST}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tWTR='${MEM_TWTR}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tRTW='${MEM_TRTW}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tCS='${MEM_TCS}'"
export GEM5_XPARAMS="${GEM5_XPARAMS} --param
system.mem_ctrls[$i].dram.device_size='${MEM_DEVICE_SIZE}'"
done

This is designed to allow things like MEM_TCK to be set before running this
piece of script, but otherwise to supply the default value 0.357ns (for
example).  Once all the above is done, the command line itself must include
${GEM5_XPARAMS} to expand out all of the above.  Also, I know its confusing,
but in an NVM only system, the NVM controllers have the name "dram" even
though that are of NVM type!

HTH - Eliot Moss


gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-leave@gem5.org

Regarding the data latency, I think it depends on whether the cache is sequential access (access cache tags, then data) or parallel access (access tags and data at the same time - common optimization for the L1 cache). See the code for BaseCache::calculateAccessLatency. If sequentialAccess==true, the sum of tag latency and data latency is used, otherwise the greater of tag latency and data latency. Regards, Fangjia ________________________________ From: Eliot Moss via gem5-users <gem5-users@gem5.org> Sent: Monday, May 1, 2023 7:46 To: The gem5 Users mailing list <gem5-users@gem5.org> Cc: Eliot Moss <moss@cs.umass.edu> Subject: [gem5-users] Re: Different latencies ---- External Email: Use caution with attachments, links, or sharing data ---- On 4/30/2023 11:33 PM, Inderjit singh via gem5-users wrote: > Any ideas. > Inderjit Singh > > On Wed, May 11, 2022 at 10:08 PM Inderjit singh <inderjitsingh.davu@gmail.com > <mailto:inderjitsingh.davu@gmail.com>> wrote: > > 1. What is the difference between data/tag/response latency? > 2. How can I add write latency (for NVM caches) in gem5, any patch? The tag part of a cache records addresses and access/state bits, typically the Valid bit (does this entry contain valid information - if not, the entry should be ignored), Dirty (does the data differ from caches farther away or the main memory), Shared (are there other copies of this line/block in other caches), etc. A cache first takes the address in the request (typically a read or write) and sees if that addresses occurs is a valid entry in the cache. The amount of time to do this is the TAG latency. The DATA latency is the additional time to supply (or update) the data if the tag matches (a cache hit). I believe the RESPONSE latency is how long it takes a cache to pass through a response coming from beyond itself. As for your question about write latency in NVM caches, I find the question a little bit ambiguous. I assume you mean volatile caches that cache information coming from NVM. DATA latency would be the write latency into such a cache. If you're talking about the internal buffers of an NVM, there are a slew of parameters in the NVM interface (which combines all the buffering, etc., with the actual data array). See NVMInterface.py, but also MemInterface.py. To set such parameters on the command line, you have to do it for each controller. This bash code might give you a sense of a way to do it using a script: # MEMORY parameters export GEM5_MEMTYPE=${GEM5_MEMTYPE:-NVM_2400_1x64} export MEM_CHANNELS=${MEM_CHANNELS:-8} export GEM5_XPARAMS="${GEM5_XPARAMS} --mem-channels=${MEM_CHANNELS}" export TOTAL_MEM_SIZE_MB=${TOTAL_MEM_SIZE_MB:-512} ## tREAD and tWRITE are guesses ... ## Other values adjusted for 2666 MHz (vs 1200MHz in default gem5) export MEM_TCK=${MEM_TCK:-0.357ns} export MEM_TREAD=${MEM_TREAD:-125ns} export MEM_TWRITE=${MEM_TWRITE:-180ns} export MEM_TSEND=${MEM_TSEND:-6.28ns} export MEM_TBURST=${MEM_TBURST:-1.528ns} export MEM_TWTR=${MEM_TWTR:-0.357ns} export MEM_TRTW=${MEM_TRTW:-0.357ns} export MEM_TCS=${MEM_TCS:-0.714ns} export MEM_DEVICE_SIZE=${MEM_DEVICE_SIZE:=$((TOTAL_MEM_SIZE_MB / MEM_CHANNELS))MB} for (( i=0 ; i < $MEM_CHANNELS ; ++i )) ; do export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tCK=\'${MEM_TCK}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tREAD=\'${MEM_TREAD}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tWRITE=\'${MEM_TWRITE}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tSEND=\'${MEM_TSEND}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tBURST=\'${MEM_TBURST}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tWTR=\'${MEM_TWTR}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tRTW=\'${MEM_TRTW}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.tCS=\'${MEM_TCS}\'" export GEM5_XPARAMS="${GEM5_XPARAMS} --param system.mem_ctrls[$i].dram.device_size=\'${MEM_DEVICE_SIZE}\'" done This is designed to allow things like MEM_TCK to be set before running this piece of script, but otherwise to supply the default value 0.357ns (for example). Once all the above is done, the command line itself must include ${GEM5_XPARAMS} to expand out all of the above. Also, I know its confusing, but in an NVM only system, the NVM controllers have the name "dram" even though that are of NVM type! HTH - Eliot Moss _______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-leave@gem5.org
EM
Eliot Moss
Tue, May 2, 2023 5:53 PM

On 5/2/2023 1:01 PM, Shen, Fangjia wrote:

Regarding the data latency, I think it depends on whether the cache is sequential access (access
cache tags, then data) or parallel access (access tags and data at the same time - common
optimization for the L1 cache).  See the code for BaseCache::calculateAccessLatency. If
sequentialAccess==true,  the sum of tag latency and data latency is used, otherwise the greater of
tag latency and data latency.

Regards,
Fangjia

Good point, Fangjia!

On 5/2/2023 1:01 PM, Shen, Fangjia wrote: > Regarding the data latency, I think it depends on whether the cache is sequential access (access > cache tags, then data) or parallel access (access tags and data at the same time - common > optimization for the L1 cache).  See the code for BaseCache::calculateAccessLatency. If > sequentialAccess==true,  the sum of tag latency and data latency is used, otherwise the greater of > tag latency and data latency. > > Regards, > Fangjia Good point, Fangjia!