Hi Jason,
thank you very much for your answer. It helped. I just wanted to give
some more background on what I'm trying to achieve.
In my case the simulation exits normally (final thread context). My test
system currently doesn't use caches (but probably will be at a later
stage). So currently, even when running a simple 'Hello World' example,
there are write packets left in the queue at the final tick.
To be specific, I am manipulating the timing of some of the write
packets and would like to check their effect on the execution time.
However, if all my modified packets are still in the queue at the end of
simulation, no difference in timing is observable.
You're probably right that I should be using full system simulation.
I'll check on that. In the meantime, I modified the memory controller in
a way to separately handle my 'special' write packets. Seems to work for
now.
Thank you again,
Vincent
Am 22.06.2021 um 17:51 schrieb Jason Lowe-Power:
Hi Vincent,
It depends on when/how you're ending the simulation. If you end the
simulation at some particular tick, then you'll see writes left in the
write queue. Just like a real machine, writes don't happen
instantaneously, and at some point in time, there are writes sitting
in the write buffer (and dirty data in the cache, too). In gem5, like
a real system, if you wanted to ensure everything is flushed to
persistent storage, you could call a flush system call. Also like a
real system, there is no instruction to flush the memory controller
write queues. The data there is architecturally visible, so it doesn't
matter if it's in the write queue or in memory.
If for some reason you really need all of the data in gem5's backing
memory (e.g., to take a checkpoint), you can call the drain() function
which will dump everything.
I believe you're really asking about timing accuracy, though. If
that's the case, I would give you two comments: (1) I would expect
that your program runs long enough that 32 cache lines that haven't
been written back to memory will make no difference in the overall
execution time. And (2) if you really need to be modeling that this
detailed of a level, you should probably be using full system mode so
you can correctly model syscalls, etc.
Hopefully this answers your question!
Cheers,
Jason
On Tue, Jun 22, 2021 at 8:06 AM Vincent R. via gem5-users
<gem5-users@gem5.org <mailto:gem5-users@gem5.org>> wrote:
Hi again,
just wanted to give this a second try. No urgent matter here, just
some
lack of understanding and curiosity on my side.
Thank you,
Vincent
Am 04.06.2021 um 11:34 schrieb Vincent R.:
> Hi everyone,
>
> I am currently doing some experiments with packet timings in the
> Memory Controller( gem5 version 20.1.0.2., SE mode). As I
understood
> it, writes accesses are serviced instantly by the controller and
their
> actual timing is only calculated later when the corresponding
> nextReqEvent is processed and the packet is removed from the
write queue.
> This works fine, however, with default parameters set, there are
still
> a lot of write packets left in the queue, when the simulation
exits.
> So, in my understanding, these are never correctly timed.
>
> As I was experimenting I set the write threshold parameters of
MemCtrl
> in a way to force the controller to process all writes.
Naturally the
> run time increases by a large amount of ticks.
>
> My question: How does gem5 perform a correct timing simulation
while
> leaving untimed writes in the queue at the end of simulation? Or
> doesn't it? Have I misunderstood something?
>
> Test system is a simple example configuration without caches.
>
>
> Thank you for your help.
> Vincent
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
<mailto:gem5-users@gem5.org>
To unsubscribe send an email to gem5-users-le...@gem5.org
<mailto:gem5-users-le...@gem5.org>
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
