gem5-users@gem5.org

The gem5 Users mailing list

View all threads

Question about response latency in Classic Cache Model

L
lsh125184@163.com
Wed, Mar 26, 2025 12:43 PM

Hello,

Recently, a response latency calculation problem in Classic Cache Model make me confused.

First, i observe the actual response latency in simulation equals the <response_latency> in Classic Cache model when transfer req from HIGHER-Level Cache (L1) to LOWER-Level Cache(L2), for example:

2360000: system.cpu.itb_walker_cache.mem_side_port: Scheduling send event at 2362000

2362000: system.l2_caches.mem_side_port: Scheduling send event at 2365000

2362000: system.l2_caches.mem_side_port: Scheduling send event at 2365000

2365000: system.l3.mem_side_port: Scheduling send event at 2368000

2368000: system.l3.mem_side_port-MemSidePort: Sending pkt ReadSharedReq [80287000:8028703f]

From itb cache(L1)->L2->L3,its’ receive TICK fits the schedule TICK perfectly.

However, when it comes to the response procedure: L3->L2->L1,i notice  that an extra 1 TICK is added to the RESPONE PORT when it responses to the scheduled event . for example:

2404926: system.l3: Scheduling 0x80287000 to response to sender 0x55a9f64e6300 at tick 2438000

2439000: system.l2_caches: recvTimingResp: Handling response ReadResp [80287000:8028703f]

2439000: system.l2_caches: Scheduling 0x80287000 to response to sender 0x55a9f609d000 at tick 2454000

2455000: system.cpu.itb_walker_cache: recvTimingResp: Handling response ReadResp [80287000:8028703f]

The above L3->L2->L1 procedure shows that the recvTimingResp is called 1-TICK after the actual TICK when the send event is scheduled.

I also print the eventQ, and it show the event is actually scheduled to printing TICK:

Event system.l2_caches.cpu_side_port-CpuSidePort.wrapped_function_event (EventFunctionWrapped)

Flags: 0x7a42

Scheduled for 2454000, priority 0

I wonder WHY the RESPONSE procedure behaves different to the SEND procedure. Does the MODEL’s wake-up function matters? As it wakes up L1->L2->L3 in  sequence every tick, so when it’s sending from L1->L2 or L2->L3, it can react simultaneously,when it comes to resp, it has to wait 1 more cycle to call recvTimingResp(). Please point it out if i am wrong.

Thanks.

Hello, Recently, a response latency calculation problem in Classic Cache Model make me confused. First, i observe the actual response latency in simulation equals the <response_latency> in Classic Cache model when transfer req from HIGHER-Level Cache (L1) to LOWER-Level Cache(L2), for example: `2360000: system.cpu.itb_walker_cache.mem_side_port: Scheduling send event at 2362000` `2362000: system.l2_caches.mem_side_port: Scheduling send event at 2365000` `2362000: system.l2_caches.mem_side_port: Scheduling send event at 2365000` `2365000: system.l3.mem_side_port: Scheduling send event at 2368000` `2368000: system.l3.mem_side_port-MemSidePort: Sending pkt ReadSharedReq [80287000:8028703f]` From itb cache(L1)->L2->L3,its’ receive TICK fits the schedule TICK perfectly. However, when it comes to the response procedure: L3->L2->L1,i notice that an extra 1 TICK is added to the RESPONE PORT when it responses to the scheduled event . for example: `2404926: system.l3: Scheduling 0x80287000 to response to sender 0x55a9f64e6300 at tick 2438000` `2439000: system.l2_caches: recvTimingResp: Handling response ReadResp [80287000:8028703f]` `2439000: system.l2_caches: Scheduling 0x80287000 to response to sender 0x55a9f609d000 at tick 2454000` `2455000: system.cpu.itb_walker_cache: recvTimingResp: Handling response ReadResp [80287000:8028703f]` The above L3->L2->L1 procedure shows that the recvTimingResp is called 1-TICK after the actual TICK when the send event is scheduled. I also print the eventQ, and it show the event is actually scheduled to printing TICK: `Event system.l2_caches.cpu_side_port-CpuSidePort.wrapped_function_event (EventFunctionWrapped)` `Flags: 0x7a42` `Scheduled for 2454000, priority 0` I wonder WHY the RESPONSE procedure behaves different to the SEND procedure. Does the MODEL’s wake-up function matters? As it wakes up L1->L2->L3 in sequence every tick, so when it’s sending from L1->L2 or L2->L3, it can react simultaneously,when it comes to resp, it has to wait 1 more cycle to call recvTimingResp(). Please point it out if i am wrong. Thanks.