Hi Leon,
Since, gem5's caches are PIPT so there should not be an aliasing problem
and you can change the latency of the cache to model a VIPT cache. Since, a
VIPT cache should not have aliasing problem if all index bits come from the
page offset (as far as I understand), maybe for a realistic
Hi Ayaz,
Thank you for your reply. In spite of your proposal, I still hope to implement
real VIPT in gem5 (20.0.0.3). If I'm to do that, do you know what files I
should modify or add and maybe something important to notice?
Looking forward to your reply!
Hello,
DRAMSim isn't a drop in replacement for the memory object anymore. Since
the change in the memory interface (
http://www.gem5.org/project/2020/10/01/gem5-20-1.html#new-dram-interface-contributed-by-wendy-elsasser)
you can't just drop in a different type of DRAM model.
You'll probably have
Hello,
The lack of error when writing a checkpoint doesn't mean it was successful.
Likely, the data was not written back to memory correctly if the random
test is failing.
No, you cannot use `writeCallbackScFail`. This is to signal that a store
conditional has failed.
It might help to learn
I would look to see how it's done in MOESI_hammer.
https://gem5.googlesource.com/public/gem5/+/refs/heads/stable/src/mem/ruby/protocol/MOESI_hammer-cache.sm#902
Cheers,
Jason
On Tue, Oct 20, 2020 at 9:04 AM 1154063264--- via gem5-users <
gem5-users@gem5.org> wrote:
> Hello Jason:
> It is
Hey Fisher,
The XBar can at maximum deliver a bandwidth equivalent to 1 packet size
(which I believe is 64 bytes) per cycle (e.g. if the clk_freq is set to
1GHz, it will at max deliver 64GBps). Does this information comply with the
results you are seeing?
Best Regards,
On Tue, Oct 13, 2020 at
Hi everyone,
I am running the pagerank algorithm that is provided by the GAP Benchmark,
and it is well known that pagerank has very bad cache utilization. But
when I run the code in GEM5 on one level of cache i get a very low
missrate, i.e. approximately 1% and it goes to a maximum of 3% for a
Hello Jason:
It is really difficult to add flush in the MESI protocol. If I need to switch
from the timing mode to KVM multiple times, do I have to add operations that
support flush to the MESI protocol?
By the way, for the cache block in the I state, it only needs to be processed
simply when
Thank you Maryam for the information.
On Wed, Oct 21, 2020 at 6:51 AM Maryam Babaie wrote:
> Hi Krishnan,
>
> As far as I probed, I can say:
> 1. in the "system.cpu.itb_walker_cache" and "system.cpu.dtb_walker_cache",
> the caches refer to TLB (instruction and data TLBs respectively).
> 2. The
In MOESI_hammer, the state transition in the I state is defined as follows,
transition({I, IR}, Flush_line, IM_F) {
it_allocateTBE;
bf_issueGETF;
k_popMandatoryQueue;
}
So I wonder if it should be defined like this in MESI_Three_Level, or simply
handle flush and keep the I state
Hi Krishnan,
As far as I probed, I can say:
1. in the "system.cpu.itb_walker_cache" and "system.cpu.dtb_walker_cache",
the caches refer to TLB (instruction and data TLBs respectively).
2. The walker refers to the page table walker.
3. No page walk cache is implemented by gem5.
Best Regards,
MB
Hi,
I am not totally sure how easy would it be to modify the current
implementation, but following pointers to understand the codebase and where
to make modifications might be useful:
to understand how virtual to physical address translation takes place look
at:
src/arch/[your ISA e.g.
Hi Ayaz,
Thank you so much for your instructions and I will look into it. By the way, if
you have any more information on implementing VIPT in gem5, please let me know!
Thanks again for your help.
___
gem5-users mailing list -- gem5-users@gem5.org
To
13 matches
Mail list logo
