[gem5-users] Re: recvAtomicLogic() in mem_ctrl.cc
On 7/11/2023 5:46 PM, Ayaz Akram via gem5-users wrote: Hi Eliot, Based on my understanding, when pkt->makeResponse() is called it updates the "cmd" of the pkt with the appropriate responseCommand (this line of code: cmd = cmd.responseCommand();) . If you look at "MemCmd::commandInfo[]" in packet.cc, the response command for a "WriteReq" command is "WriteResp". And the attributes of a "WriteResp" command don't have "HasData", which is why the response pkt will return false on a "hasData()" check. You might also want to look at the struct CommandInfo in packet.hh. Ah, yes - I was confusing hasData with the STATIC_DATA and DYNAMIC_DATA properties, which have to do with whether the data field is set (and with whether it needs to be deleted when the packet is deleted), which is separate from the logical notion of whether the packet is carrying data from one place to another. Thanks for the reminder! EM ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: recvAtomicLogic() in mem_ctrl.cc
Thank you Elliot and Ayaz for the well explained responses. I understood the code snippet now. On Tue, Jul 11, 2023 at 5:46 PM Ayaz Akram wrote: > Hi Eliot, > > Based on my understanding, when pkt->makeResponse() is called it updates > the "cmd" of the pkt with the appropriate responseCommand (this line of > code: cmd = cmd.responseCommand();) . If you look at > "MemCmd::commandInfo[]" in packet.cc, the response command for a > "WriteReq" command is "WriteResp". And the attributes of a "WriteResp" > command don't have "HasData", which is why the response pkt will return > false on a "hasData()" check. > > You might also want to look at the struct CommandInfo in packet.hh. > > -Ayaz > > On Tue, Jul 11, 2023 at 2:15 PM Eliot Moss via gem5-users < > gem5-users@gem5.org> wrote: > >> On 7/11/2023 3:03 PM, John Smith wrote: >> > Thanks for responding, Elliot. I somewhat understand that after the >> write is accomplished, the >> > returning packet won't have the data. But still, why is the returned >> value 0 in that case? Shouldn't >> > it still be equal to the memory access latency. >> >> In the Atomic case this code is assuming the write can >> be absorbed into a write buffer, so there is no additional >> latency visible to the user. Of course it is *possible* to >> saturate the buffers, and if you want a more accurate >> accounting you can use a Timing model instead. >> >> EM >> ___ >> gem5-users mailing list -- gem5-users@gem5.org >> To unsubscribe send an email to gem5-users-le...@gem5.org >> > ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: recvAtomicLogic() in mem_ctrl.cc
Hi Eliot, Based on my understanding, when pkt->makeResponse() is called it updates the "cmd" of the pkt with the appropriate responseCommand (this line of code: cmd = cmd.responseCommand();) . If you look at "MemCmd::commandInfo[]" in packet.cc, the response command for a "WriteReq" command is "WriteResp". And the attributes of a "WriteResp" command don't have "HasData", which is why the response pkt will return false on a "hasData()" check. You might also want to look at the struct CommandInfo in packet.hh. -Ayaz On Tue, Jul 11, 2023 at 2:15 PM Eliot Moss via gem5-users < gem5-users@gem5.org> wrote: > On 7/11/2023 3:03 PM, John Smith wrote: > > Thanks for responding, Elliot. I somewhat understand that after the > write is accomplished, the > > returning packet won't have the data. But still, why is the returned > value 0 in that case? Shouldn't > > it still be equal to the memory access latency. > > In the Atomic case this code is assuming the write can > be absorbed into a write buffer, so there is no additional > latency visible to the user. Of course it is *possible* to > saturate the buffers, and if you want a more accurate > accounting you can use a Timing model instead. > > EM > ___ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org > ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: recvAtomicLogic() in mem_ctrl.cc
On 7/11/2023 3:03 PM, John Smith wrote: Thanks for responding, Elliot. I somewhat understand that after the write is accomplished, the returning packet won't have the data. But still, why is the returned value 0 in that case? Shouldn't it still be equal to the memory access latency. In the Atomic case this code is assuming the write can be absorbed into a write buffer, so there is no additional latency visible to the user. Of course it is *possible* to saturate the buffers, and if you want a more accurate accounting you can use a Timing model instead. EM ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: recvAtomicLogic() in mem_ctrl.cc
On 7/11/2023 3:20 PM, Ayaz Akram via gem5-users wrote: Hi John, If you are checking if the pkt is write when pkt->hasData() condition is true in recvAtomicLogic() function, the check (pkt_is_write) will always be false. The reason is that a write pkt would have already written its data to the memory (abstract memory) in the previous line of code "mem_intr->access(pkt);" That access to the memory interface converts a request pkt into a response pkt and adds or removes data from the pkt (depending on if the request was a read or a write). Also, in this implementation, the accessLatency will only be returned if the request was a read request i.e., the write requests would not see any latency. Dear Ayaz - That makes sense to me, but I could not find where the dropping of the data happens in the code. The makeResponse function on packets does not affect the data, and neither does the writeData function (which grabs the data and copies it to the memory). If you know where this happens, it might improve John's and my understandings of how this code path works. Regards - Eliot ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: recvAtomicLogic() in mem_ctrl.cc
Hi John, If you are checking if the pkt is write when pkt->hasData() condition is true in recvAtomicLogic() function, the check (pkt_is_write) will always be false. The reason is that a write pkt would have already written its data to the memory (abstract memory) in the previous line of code "mem_intr->access(pkt);" That access to the memory interface converts a request pkt into a response pkt and adds or removes data from the pkt (depending on if the request was a read or a write). Also, in this implementation, the accessLatency will only be returned if the request was a read request i.e., the write requests would not see any latency. -Ayaz On Tue, Jul 11, 2023 at 12:06 PM John Smith via gem5-users < gem5-users@gem5.org> wrote: > Thanks for responding, Elliot. I somewhat understand that after the write > is accomplished, the returning packet won't have the data. But still, why > is the returned value 0 in that case? Shouldn't it still be equal to the > memory access latency. > > On Tue, Jul 11, 2023 at 2:34 PM Eliot Moss wrote: > >> On 7/11/2023 1:28 PM, John Smith via gem5-users wrote: >> > So, I used the function pkt->isWrite() to check if the packet is a >> write request. And I observed >> > that inside the pkt->hasData() if condition, pkt->isWrite() returned >> false. Hence only the read >> > packets were entering the if(pkt->hasData()) condition >> >> So you're saying that inside the if condition, pkt->isWrite is *always* >> false? >> >> I see. I couldn't find a place in the code (in the version I have >> downloaded >> anyway) where the data is dropped, but I can imagine it happening after >> the >> write is accomplished (though I don't see why), so that the "returning" >> packet no longer has data. What are the exact types of the components >> involved? And maybe someone else is more competent to answer this since >> it >> is somewhat stumping me from my reading of the code. >> >> Cheers - Eliot >> > ___ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org > ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: recvAtomicLogic() in mem_ctrl.cc
Thanks for responding, Elliot. I somewhat understand that after the write is accomplished, the returning packet won't have the data. But still, why is the returned value 0 in that case? Shouldn't it still be equal to the memory access latency. On Tue, Jul 11, 2023 at 2:34 PM Eliot Moss wrote: > On 7/11/2023 1:28 PM, John Smith via gem5-users wrote: > > So, I used the function pkt->isWrite() to check if the packet is a write > request. And I observed > > that inside the pkt->hasData() if condition, pkt->isWrite() returned > false. Hence only the read > > packets were entering the if(pkt->hasData()) condition > > So you're saying that inside the if condition, pkt->isWrite is *always* > false? > > I see. I couldn't find a place in the code (in the version I have > downloaded > anyway) where the data is dropped, but I can imagine it happening after the > write is accomplished (though I don't see why), so that the "returning" > packet no longer has data. What are the exact types of the components > involved? And maybe someone else is more competent to answer this since it > is somewhat stumping me from my reading of the code. > > Cheers - Eliot > ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: recvAtomicLogic() in mem_ctrl.cc
On 7/11/2023 1:28 PM, John Smith via gem5-users wrote: So, I used the function pkt->isWrite() to check if the packet is a write request. And I observed that inside the pkt->hasData() if condition, pkt->isWrite() returned false. Hence only the read packets were entering the if(pkt->hasData()) condition So you're saying that inside the if condition, pkt->isWrite is *always* false? I see. I couldn't find a place in the code (in the version I have downloaded anyway) where the data is dropped, but I can imagine it happening after the write is accomplished (though I don't see why), so that the "returning" packet no longer has data. What are the exact types of the components involved? And maybe someone else is more competent to answer this since it is somewhat stumping me from my reading of the code. Cheers - Eliot ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: recvAtomicLogic() in mem_ctrl.cc
So, I used the function pkt->isWrite() to check if the packet is a write request. And I observed that inside the pkt->hasData() if condition, pkt->isWrite() returned false. Hence only the read packets were entering the if(pkt->hasData()) condition On Tue, Jul 11, 2023 at 1:10 PM Eliot Moss wrote: > On 7/11/2023 1:01 PM, Eliot Moss wrote: > > On 7/11/2023 12:52 PM, John Smith wrote: > >> Okay, but I've also noticed that a WriteReq generally carries no data. > Why exactly is that? Cause > >> if we are writing to memory, then the memory access latency shouldn't > be 0 right? > > > > I believe that happens if the write got its data by snooping a cache. > > The packet still goes to the memory, but with the write suppressed. > > This certainly happens in the Timing case; I admit I'm a little less > > clear about the Atomic one. > > Sorry - I see I was responding about a read. > > So, what surprises me is that you're saying that write requests generally > carry no data. That doesn't seem right. What leads you to that > conclusion? > > Best - EM > ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: recvAtomicLogic() in mem_ctrl.cc
On 7/11/2023 1:01 PM, Eliot Moss wrote: On 7/11/2023 12:52 PM, John Smith wrote: Okay, but I've also noticed that a WriteReq generally carries no data. Why exactly is that? Cause if we are writing to memory, then the memory access latency shouldn't be 0 right? I believe that happens if the write got its data by snooping a cache. The packet still goes to the memory, but with the write suppressed. This certainly happens in the Timing case; I admit I'm a little less clear about the Atomic one. Sorry - I see I was responding about a read. So, what surprises me is that you're saying that write requests generally carry no data. That doesn't seem right. What leads you to that conclusion? Best - EM ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: recvAtomicLogic() in mem_ctrl.cc
On 7/11/2023 12:52 PM, John Smith wrote: Okay, but I've also noticed that a WriteReq generally carries no data. Why exactly is that? Cause if we are writing to memory, then the memory access latency shouldn't be 0 right? I believe that happens if the write got its data by snooping a cache. The packet still goes to the memory, but with the write suppressed. This certainly happens in the Timing case; I admit I'm a little less clear about the Atomic one. Best - EM ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: recvAtomicLogic() in mem_ctrl.cc
Okay, but I've also noticed that a WriteReq generally carries no data. Why
exactly is that? Cause if we are writing to memory, then the memory access
latency shouldn't be 0 right?
On Tue, Jul 11, 2023 at 12:49 PM Eliot Moss wrote:
> On 7/11/2023 12:37 PM, John Smith via gem5-users wrote:
> > Hi everyone,
> >
> > Could someone please help me with explaining what's happening in the
> below code snippet? It's the
> > receiveAtomicLogic() function in mem_ctrl.cc. Why are we returning the
> latency as 0 if the packet
> > doesn't have any data? And in what case will the packet have/not have
> data?
> >
> > // do the actual memory access and turn the packet into a response
> >
> > mem_intr->access(pkt);
> >
> >
> > if (pkt->hasData()) {
> >
> > // this value is not supposed to be accurate, just enough to
> >
> > // keep things going, mimic a closed page
> >
> > // also this latency can't be 0
> >
> > return mem_intr->accessLatency();
> >
> > }
> >
> >
> > return 0;
>
> John - Certain packets carry no data. For example, a cache line invalidate
> without write back will have that property. Maybe others.
>
> Best - Eliot
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: recvAtomicLogic() in mem_ctrl.cc
On 7/11/2023 12:37 PM, John Smith via gem5-users wrote:
Hi everyone,
Could someone please help me with explaining what's happening in the below code snippet? It's the
receiveAtomicLogic() function in mem_ctrl.cc. Why are we returning the latency as 0 if the packet
doesn't have any data? And in what case will the packet have/not have data?
// do the actual memory access and turn the packet into a response
mem_intr->access(pkt);
if (pkt->hasData()) {
// this value is not supposed to be accurate, just enough to
// keep things going, mimic a closed page
// also this latency can't be 0
return mem_intr->accessLatency();
}
return 0;
John - Certain packets carry no data. For example, a cache line invalidate
without write back will have that property. Maybe others.
Best - Eliot
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
