Hello Nikos and Everyone,

In src/mem/cache/cache.cc for function handleTimingReqMiss(), we only check
if there is an existing mshr entry corresponding to Miss Request. And then
we call  *BaseCache::handleTimingReqMiss(pkt, mshr, blk, forward_time,
request_time);*

In BaseCache::handleTimingReqMiss(pkt, mshr, blk, forward_time,
request_time) function if its the first time the cache line is having a
miss we create MSHR entry by calling allocateMissbuffer which is defined in
base.hh, this allocateMissBuffer function creates new MSHR entry and first
target or that entry, so I have modified allcateMissBuffer in base.hh to :

   MSHR *allocateMissBuffer(PacketPtr pkt, Tick time, bool sched_send =
true)

    {

        MSHR *mshr = mshrQueue.allocate(pkt->getBlockAddr(blkSize), blkSize,

                                        pkt, time, order++,

                                        allocOnFill(pkt->cmd));


        if (mshrQueue.isFull()) {

            setBlocked((BlockedCause)MSHRQueue_MSHRs);

        }


*        if (mshr->getNumTargets() == numTarget) {*



*            //cout << "Blocked: " << name() << endl;*

*            noTargetMSHR = mshr;*

*            setBlocked(Blocked_NoTargets);*

*        }*


        if (sched_send) {

            // schedule the send

            schedMemSideSendEvent(time);

        }


        return mshr;

    }

What highlighted part does it blocks the cache from receiving any request
from LSQ until we get clear the MSHR entry through recvTimingResp function.
Note that *mshr->getNumTargets() *will always be one as this is the very
first time an MSHR entry is created. But somehow I do not think this is
correctas the simulation is not terminating but it does when hello binary
is tested.

Now if in baseline gem5 the current commit if we* set tgts_per_mshr from
configs/common/Caches.py *for dcache to 1 and compare the stats with *
tgts_per_mshr
set to 2 *we can clearly see that * tgts_per_mshr set to 2 * has more
cycles from stat *system.cpu.dcache.blocked:**:no_targets* when compared to
1 target per mshr. This is because we never blocked the requests coming to
Dcache when we had only one target per MSHR.


Best regards,

Abhishek


On Mon, Mar 25, 2019 at 5:09 PM Nikos Nikoleris <nikos.nikole...@arm.com>
wrote:

> Abhishek,
>
> In that case the code you should be looking at is in
> src/mem/cache/cache.cc in the function handleTimingReqMiss()
>
> mshr->allocateTarget(pkt, forward_time, order++,
>                       allocOnFill(pkt->cmd));
> if (mshr->getNumTargets() == numTarget) {
>      noTargetMSHR = mshr;
>      setBlocked(Blocked_NoTargets);
> }
>
> I'm not sure why you don't see any stalls due to no_targets. You might
> want to check how we measure the relevant stats and also make sure that
> the simulation you run will trigger this.
>
> Nikos
>
>
> On 25/03/2019 20:19, Abhishek Singh wrote:
> > I want to have just 1 target per cache line in MHSR queue ie., one
> > target per MSHR entry, but if I set parameter tgt_per_mshr to be 1, I
> > get the number of blocked cycles to zero i.e, there is no blocking due
> > to full targets.
> >
> > If we see the allocateMissBuffer calls code in base.cc and base.hh, the
> > first time we allocate entry to a miss we create a mshr entry and target
> > for that and do not check the tgts_per_mshr parameter. The second time
> > when a miss occurs to the same cache line, we create target for that and
> > then check tgts_per_mshr to block the future requests.
> >
> > The quicker way to find if tgt_per_mshr is working or not when set to 1
> > is to check number for system.cpu.dcache.blocked::no_targets in
> > m5out/stats.txt.
> >
> >
> > Best regards,
> >
> > Abhishek
> >
> >
> >
> > On Mon, Mar 25, 2019 at 4:05 PM Nikos Nikoleris <nikos.nikole...@arm.com
> > <mailto:nikos.nikole...@arm.com>> wrote:
> >
> >     Hi Abishek,
> >
> >     A single MSHR can keep track of more than one requests for a given
> cache
> >     line. If you set tgts_per_mshr to 1, then the MSHR will only be able
> to
> >     keep track of a single request for any given cache line. But it can
> >     still service requests to other cache lines by allocating more MSHRs.
> >
> >     If you want the cache to block on a single request you will need to
> >     limit both the number of MSHRs and tgts_per_mshr to 1.
> >
> >     I hope this helps.
> >
> >     Nikos
> >
> >     On 25/03/2019 19:03, Abhishek Singh wrote:
> >      > Hello Everyone,
> >      >
> >      > I am trying to simulate D-cache with one target per mshr, I tried
> >      > changing the parameter "tgts_per_mshr" defined in
> >      > "configs/common/Caches.py"  to 1, it does not work.
> >      >
> >      > This is because when we allocate target for existing MSHR, we
> always
> >      > check the  "tgts_per_mshr" parameter after allocating the second
> >     target
> >      > and blocks the requests coming from LSQ.
> >      >
> >      > I tried copying the blocking target code to an allocateMissBuffer
> >      > function defined and declared in "src/mem/cache/base.hh" as:
> >      >
> >      >
> >      > *_BEFORE_*:
> >      >
> >      > MSHR *allocateMissBuffer(PacketPtr pkt, Tick time, bool
> >     sched_send = true)
> >      >
> >      > {
> >      >
> >      > MSHR *mshr = mshrQueue.allocate(pkt->getBlockAddr(blkSize),
> blkSize,
> >      >
> >      > pkt, time, order++,
> >      >
> >      > allocOnFill(pkt->cmd));
> >      >
> >      >
> >      > if (mshrQueue.isFull()) {
> >      >
> >      > setBlocked((BlockedCause)MSHRQueue_MSHRs);
> >      >
> >      > }
> >      >
> >      >
> >      > if (sched_send) {
> >      >
> >      > // schedule the send
> >      >
> >      > schedMemSideSendEvent(time);
> >      >
> >      > }
> >      >
> >      >
> >      > return mshr;
> >      >
> >      > }
> >      >
> >      >
> >      >
> >      > *_AFTER:_*
> >      >
> >      >
> >      >
> >      > MSHR *allocateMissBuffer(PacketPtr pkt, Tick time, bool
> >     sched_send = true)
> >      >
> >      > {
> >      >
> >      > MSHR *mshr = mshrQueue.allocate(pkt->getBlockAddr(blkSize),
> blkSize,
> >      >
> >      > pkt, time, order++,
> >      >
> >      > allocOnFill(pkt->cmd));
> >      >
> >      >
> >      > if (mshrQueue.isFull()) {
> >      >
> >      > setBlocked((BlockedCause)MSHRQueue_MSHRs);
> >      >
> >      > }
> >      >
> >      >
> >      > *if (mshr->getNumTargets() == numTarget) {*
> >      >
> >      > **
> >      >
> >      > *//cout << "Blocked: " << name() << endl;*
> >      >
> >      > *noTargetMSHR = mshr;*
> >      >
> >      > *setBlocked(Blocked_NoTargets);*
> >      >
> >      > *}*
> >      >
> >      > *
> >      > *
> >      >
> >      > if (sched_send) {
> >      >
> >      > // schedule the send
> >      >
> >      > schedMemSideSendEvent(time);
> >      >
> >      > }
> >      >
> >      >
> >      > return mshr;
> >      >
> >      > }
> >      >
> >      >
> >      > I also change the "tgts_per_mshr" defined in
> >     "configs/common/Caches.py"
> >      > to 1.
> >      >
> >      > But simulation goes into an infinite loop and does not end.
> >      >
> >      > Does anyone have the technique to create Blocking caches with 1
> >      > target per MSHR entry?
> >      >
> >      >
> >      >
> >      > Best regards,
> >      >
> >      > Abhishek
> >      >
> >     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 <mailto: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

Reply via email to