P {margin-top:0;margin-bottom:0;} An interesting thing that I found when analyzing GEM5 output, is that core 7 hits the reset stats after core 0 finishes, this happens in very special scenario if scheduling favorites a core over another, so now this makes sense.
From: Abdlerhman Abotaleb via gem5-users <gem5-users@gem5.org>
Sent: Saturday, July 1, 2023 10:41 PM
To: Balazs Gerofi via gem5-users <gem5-users@gem5.org>
Cc: Abdlerhman Abotaleb <abotalea@mcmaster.ca>
Subject: [gem5-users] Reset Stats Unexpected Results for multiCore
<!--
p
{margin-top:0;
margin-bottom:0}
-->
Caution: This email may have originated from outside the organization. Please exercise additional caution with any links and attachments.
How reset stats work in case of multicore ?
I run multicore experiment with 8 cores running the same binary.
The binary has m5_reset_stats(0,0); before code of interest which is a loop that runs huge number of iterations (for example 100k ~ access 781kB of data ,in case of double type item is accessed each loop iteration)) .
The results sometimes appear to be fine , i.e. numCycles per all cores are almost equal
But in other situations, with same code but applying different memory scheduling technique , some cores have 0 "system.cpux.numCycles", even that in GEM5 output I can see that the corresponding code is working and produces the desired output per each core!
Is it expected , Should I use reset stats in different way ?
Thank you.
