Hi,

I'm also very interested about this issue.

Could you please specify more about where to look at the response latencies
of LDR/STR requests at the CPU side?

Thanks,

Tiansheng

On Mon, Jan 26, 2015 at 11:46 AM, Jack Harvard via gem5-users <
[email protected]> wrote:

> How about checking the response latencies of LDR/STR requests at CPU
> side, the longest response latency indicates memory accesses, without
> keeping track of addresses that are sent to the DRAM controller.
>
> Normally, if I understand what you are trying to do correctly, you
> need to keep track of the address range of the stack [stack_pointer,
> stack_top], the address range of the stack is virtual. And you need to
> keep track of the addresses going into the memory, which are physical.
> You need to convert the physical addresses to virtual addresses, and
> see whether the addresses fall inside the stack range.
>
> Hope this helps?
>
> Jack
> Jack Harvard
>
>
> On Mon, Jan 26, 2015 at 4:25 PM, Leonardo Ecco via gem5-users
> <[email protected]> wrote:
> > I'm currently struggling to trace accesses to the software stack that
> > are not found in the cache (and, therefore, must be forwarded to the
> > DRAM).
> > By stack I mean the portion of memory dedicated to the stack (as in
> > the figure below).
> >
> > ---------------
> > |   Stack    |
> > |        ||      |   => Portion of memory that I'd like to keep track of.
> > |        \/      |
> > |                |
> > |                |
> > |       /\       |
> > |       ||       |
> > |    Heap   |
> > ---------------
> > |     bss     |
> > ---------------
> > |     data    |
> > ---------------
> > |      text    |
> > ---------------
> >
> >
> > Does anyone envision a way to do this without keeping track of the
> > addresses that are sent to the DRAM controller?
> > Is this something that a communication monitor could keep track of?
> > _______________________________________________
> > gem5-users mailing list
> > [email protected]
> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to