Is there any limitation on issue width from LSQ queue to L1 cache? Where I can find that issue width? I am talking about number of parallel access issued to L1 cache.
On Mon, Aug 6, 2018 at 3:25 AM Nikos Nikoleris <nikos.nikole...@arm.com> wrote: > Hi Abishek, > > > > Timon is right. In gem5 the caches implement a write-back policy. When > there is an eviction of a dirty block from L1 then it will be written back > to L2. In rare exceptions where allocation is not possible in the L2 (e.g., > there is a pending request for the victim block), the writeback will be > sent to the memory below. > > > > As for your first question and as Timon pointed out, if you have a request > for block X which misses in the L1 it will send a request to the memory > below and it will allocate an MSHR while it is waiting for the response. If > the cache receives another request for the same block X before the response > comes back and if the two requests can be serviced together (e.g., both > read from X) the cache will coalesce the second request with the first and > will service both of them at once when the response arrives to L1. > > > > Nikos > > > > *From: *gem5-users <gem5-users-boun...@gem5.org> on behalf of Timon > Evenblij <evenblij.ti...@gmail.com> > *Reply-To: *gem5 users mailing list <gem5-users@gem5.org> > *Date: *Monday, 6 August 2018 at 06:56 > *To: *gem5 users mailing list <gem5-users@gem5.org> > *Subject: *Re: [gem5-users] Cache Management > > > > Hi Abishek, > > > > Everything is possible, it all depends on the cache policy. I think the > default behavior in gem5 is a write-back cache, and I am not sure if any > other policies are implemented (Can someone else confirm?). A write-back > cache only writes the data back upon eviction, unlike a write-trough cache > were all levels are updated at write time. So, for your example: if both L1 > and L2 are write-back caches, then the block in L2 gets updated after > eviction from L1. Only later, when the block gets evicted from L2, then the > content is written in main-memory. > > > > Best regards > > > > On Sun, Aug 5, 2018 at 3:59 PM Abhishek Singh < > abhishek.singh199...@gmail.com> wrote: > > Hi Timon, > > I had one question eviction of write back. > > What happens when a dirty block is evicted from L1 cache. Does it check L2 > cache updates the content of that block in L2 and then goes to memory and > update contents in memory ? > > > > On Thu, Aug 2, 2018 at 4:04 AM Timon Evenblij <evenblij.ti...@gmail.com> > wrote: > > Hi Abishek, > > > > No, for this case, MSHRs (miss status handling registers) exists. These > are registers that keep track of missed cache accesses (in your case packet > 1 that misses in L1), so the cache can be freed to reply to other accesses > (packet 2) while waiting for the answer of the miss (packet 1 gets answered > from L2 or even further away). > > > > Best regards, > > > > Timon > > > > On Thu, Aug 2, 2018 at 2:30 AM Abhishek Singh < > abhishek.singh199...@gmail.com> wrote: > > My question is simple if there are two packets wants to access L1 cache in > a system of 2 level cache and cpu is o3. Will packet 2 has to wait for > packet 1 to get its response(packet 1) from L2 in case of L1 cache miss and > L2 cache hit? > > What happen if its L2 miss? > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
