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> 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 > To unsubscribe send an email to 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
