Hi,
I'm trying to figure out how "clflush" instruction works in gem5.
Specially, how it issues a signal to the cache controller to evict the
block from cache hierarchy throughout the system and how it receives
confirmation to clean the store buffer so that the next fence let following
instructions to proceed. Anyone have any idea how this works or where I
should look for better understanding ?
I have tried to trace clflush execution and found some confusing facts. It
would be great if anyone could clarify this.
1. "clflush" instruction execution eventually calls
Clflushopt::initiateAcc() (build/X86/arch/x86/generated/exec-ns.cc.inc ) as
macroop definition of CLFLUSH uses clflushopt. So, there is no dedicated
clflush operation in gem5 but all flush operations are treated as
clflushopt ?
2. When Clflushopt::initiateAcc() executes in timing simulation (
CPUType::TIMING), it eventually calls TimingSimpleCPU::writeMem() function
in src/cpu/simple/timing.cc. Here you have :
if (data == NULL) {
> assert(flags & Request::STORE_NO_DATA);
> // This must be a cache block cleaning request
> memset(newData, 0, size);
> } else {
> memcpy(newData, data, size);
> }
>
So, I was assuming it will have data==NULL and execute memset() but it
actually executes memcpy(). This seems weird. Am I missing something ?
3. For out-of-order simulation (CPUType.O3), Clflush::initiateAcc() is
called twice the number of clflush instructions in my workload. For
example, if my workload has 6 clflush instructions, gdb breakpoint at
Clflush::initiateAcc shows that this function is called 12 times (timing
simulation called this function 6 times as it should). Can anyone explain
what happens here?
Best
shaikhul
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
