Hi Shuai,
First of all sorry for the late answer. I am afraid that my knowledges
of the memory system in gem5 are not very deep... However, I think that
maybe this problem could be related to the translation of logical to
physical address. While in the assembler code you can see the direction
0x5891e0 + offsset (e.g: 1 or 193 in your case), you don't know to which
physical address the logical address will be translated to, so the
problem may come from there.
Regarding your question about translating the addresses from gem5 to the
physical machine, I think it is not possible. Simply because you "can't"
know which memory region is granted to each running process. So we could
say that the address space assigned to your process is most likely to
vary every time you run it, which makes the translation impossible.
I hope this helped,
Ferran O.
On 28/12/16 21:48, Shuai Wang wrote:
Hello Ferran,
Thank you so much for your help! I tried the approach you suggested,
and it works pretty well! I really appreciate your help :)
After going through the tracked memory access information, there is
still one thing that confuses me a lot. At your connivence, could you
please take a look and shed some light on it? Thank you a lot in advance.
Suppose I am trying to analyze the cache access of the instruction below:
0x404a83: movzbl 0x5891e0(%rdx),%eax
In the dumped trace, by searching the program counter (i.e.,
0x404a83), I observed two cache access of the above instruction (very
consistent with my inference on the source code, which's great ! )
like below:
r,497492449,1,3,5587298761000,4213379
...
r,499049121,1,3,5608120191500,4213379
...
The value in the second column should be the accessed memory address
of each cache access, which is 497492449 or 499049121.
However, my debugging results of the above instruction on a physical
machine shows that register %rdx equals to 1 or 193, and the
corresponding accessed memory address should be 0x5891e0 + 1 =
0x5891e1 or 0x5891e0 + 193 = 5804705.
I understood that memory address could be very different comparing the
physical machine with the gem5 simulated machine. However, I basically
have no idea how should I interpret the tracked memory addresses. For
example, one accessed memory address is larger than the other one in
terms of 192 on the physical machine, while I cannot figure out such
relation in the simulated results...
Is there any way I can interpret/translate the captured memory
addresses on the simulated OS into corresponding memory addresses on
the physical machines? Or basically there is no way to do that...?
Any suggestion would be really appreciated! Thank you a lot and wish
you all the best!
Sincerely,
Shuai
On Wed, Dec 28, 2016 at 5:10 AM, Ferran Olid <[email protected]
<mailto:[email protected]>> wrote:
Hi Shuai,
What you could do is booting the system with the atomic CPU and
just when finished booting, create a checkpoint and exit (you can
do this with the flag --checkpoint-at-exit or something like
this). Afterwards, you resume the checkpoint using the CPU you
want and monitoring everything. In addition, if you do it this way
you can modify the memory hierarchy or the CPU model and, as long
as there are no changes in the script or in the disk you're using
for the full system, there's no need to boot it again.
Hope this helped,
Ferran O
On 28/12/16 04:35, Shuai Wang wrote:
Dear list,
I am using gem5 full system simulation to run a 64-bit x86
application, and trying to capture the memory access towards the
L1 DCache.
I have successfully setup the whole full system simulation
environment (Ubuntu 12.04 64-bit, Kernel version 3.2.1). I
modified the code in configs/common/CacheConfig.py to equip my
simulated system with L1 ICache and DCache, and intercept the
communication between CPU and DCache with a common monitoring.
My current observation is that, during the booting of the
simulated system, it seems stuck at the *init_memory_mapping
*procedure**after almost half an hour. I past the output of the
booting process below:
☁ term [master] ⚡ ./m5term localhost 3456
==== m5 slave terminal: Terminal 0 ====
Linux version 3.2.1 (szw175@lrs-dwu01) (gcc version 4.8.1 (Ubuntu
4.8.1-2ubuntu1~12.04) ) #2 Tue Dec 27 14:24:46 EST 2016
Command line: earlyprintk=ttyS0 console=ttyS0 lpj=7999923
root=/dev/hda1
CPU: vendor_id 'M5 Simulator' unknown, using generic init.
CPU: Your system may be unstable.
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
BIOS-e820: 0000000020000000 - 00000000c0000000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
bootconsole [earlyser0] enabled
NX (Execute Disable) protection: active
DMI 2.5 present.
No AGP bridge found
last_pfn = 0x20000 max_arch_pfn = 0x400000000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
CPU MTRRs all blank - virtualized system.
found SMP MP-table at [ffff8800000f0050] f0050
init_memory_mapping: 0000000000000000-0000000020000000
I understand that such CPU<->DCache monitoring could be very time
consuming, and it seems reasonable for such slow booting.
However, I would like to inquire about two questions at this
step, in case I didn't screw things up..
1. Note that I am trying to monitor the cache access of an
application code in the simulated OS, so basically it is
meaningless to start the monitoring at the very beginning. So I
am wondering if there is any chance that I can skip the
monitoring during the OS booting; the monitoring can start right
after the OS booting.
My application code cannot run under the syscall simulation
mode, so that's why I need the full system mode..
2. Is there any "best practice" that I can use to boost the OS
booting procedure under monitoring?
Any advice or suggestion would be strongly appreciated! Thank you.
Sincerely,
Shuai
_______________________________________________
gem5-users mailing list
[email protected] <mailto:[email protected]>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
_______________________________________________ gem5-users mailing
list [email protected] <mailto:[email protected]>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
<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
