[gem5-users] Increasing TLB size not working for X86 with O3CPU

Discussion:

Da Zhang

2018-05-24 15:44:00 UTC

Hey guys,

I tried to increase the dtb size (i.e., number of tlb entries) for our
research. However, the stats.txt for the different dtb size
(64,128,256,512,1024,2048,1048576) is practical identical or identical. For
size < 512, the system.switch_cpus.dtb.rdAccesses difference is only
several hundred. For size > 512, the whole stats.txt is identical. I am
working for the X86 architecture. I change the size in X86TLB.py to
increase the dtb size. By checking the config.ini file, I see the size is
set as expected (under system.cpu.dtb). Any clue?

Thanks in advance.

Best,
Da

Jason Lowe-Power

2018-05-24 16:00:47 UTC

Permalink

Hi Da,

Are you using SE mode or FS mode? IIRC, the TLB size does nothing in SE
mode (it doesn't use a TLB). The TLB is only used in FS mode.

Jason

Post by Da Zhang
Hey guys,
I tried to increase the dtb size (i.e., number of tlb entries) for our
research. However, the stats.txt for the different dtb size
(64,128,256,512,1024,2048,1048576) is practical identical or identical. For
size < 512, the system.switch_cpus.dtb.rdAccesses difference is only
several hundred. For size > 512, the whole stats.txt is identical. I am
working for the X86 architecture. I change the size in X86TLB.py to
increase the dtb size. By checking the config.ini file, I see the size is
set as expected (under system.cpu.dtb). Any clue?
Thanks in advance.
Best,
Da
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Da Zhang

2018-05-24 16:10:48 UTC

Permalink

I am using FS mode.

Post by Jason Lowe-Power
Hi Da,
Are you using SE mode or FS mode? IIRC, the TLB size does nothing in SE
mode (it doesn't use a TLB). The TLB is only used in FS mode.
Jason

Post by Da Zhang
Hey guys,
I tried to increase the dtb size (i.e., number of tlb entries) for our
research. However, the stats.txt for the different dtb size
(64,128,256,512,1024,2048,1048576) is practical identical or identical.
For size < 512, the system.switch_cpus.dtb.rdAccesses difference is only
several hundred. For size > 512, the whole stats.txt is identical. I am
working for the X86 architecture. I change the size in X86TLB.py to
increase the dtb size. By checking the config.ini file, I see the size is
set as expected (under system.cpu.dtb). Any clue?
Thanks in advance.
Best,
Da
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Jason Lowe-Power

2018-05-28 16:03:55 UTC

Permalink

Hi Da,

"For size > 512, the whole stats.txt is identical."

This isn't surprising. 512*4KB = 2MB. So, if your workload is only 1MB when
you have at least 512 entries you are only seeing compulsory (cold) misses.
Try running larger workloads and/or workloads with more reuse.

Cheers,
Jason

Post by Da Zhang
I am using FS mode.

Post by Jason Lowe-Power
Hi Da,
Are you using SE mode or FS mode? IIRC, the TLB size does nothing in SE
mode (it doesn't use a TLB). The TLB is only used in FS mode.
Jason

_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Da Zhang

2018-05-28 17:55:21 UTC

Permalink

Hi, Jason

Sorry for my unclear description before. For our workload,
the switch_cpus.dtb's miss rate for 64 tlb entries is 154654 / 1589214 =
9.74%; the miss rate for 1048576 tlb entries is 154360 / 1583757 = 9.73%.
Both are running for 20ms warm up in atomic mode and 2.5ms real simulation
with O3CPU. They are practically identical and very high especially for
1048576 entries with only 1MB heap size.

Any idea or suggestions? Please let me know if other statistics or config
information will be helpful.

best,
Da

Post by Jason Lowe-Power
Hi Da,
"For size > 512, the whole stats.txt is identical."
This isn't surprising. 512*4KB = 2MB. So, if your workload is only 1MB
when you have at least 512 entries you are only seeing compulsory (cold)
misses. Try running larger workloads and/or workloads with more reuse.
Cheers,
Jason

Post by Da Zhang
I am using FS mode.

Post by Jason Lowe-Power
Hi Da,
Are you using SE mode or FS mode? IIRC, the TLB size does nothing in SE
mode (it doesn't use a TLB). The TLB is only used in FS mode.
Jason

Post by Da Zhang
Hey guys,
I tried to increase the dtb size (i.e., number of tlb entries) for our
research. However, the stats.txt for the different dtb size
(64,128,256,512,1024,2048,1048576) is practical identical or
identical. For size < 512, the system.switch_cpus.dtb.rdAccesses difference
is only several hundred. For size > 512, the whole stats.txt is identical.
I am working for the X86 architecture. I change the size in X86TLB.py to
increase the dtb size. By checking the config.ini file, I see the size is
set as expected (under system.cpu.dtb). Any clue?
Thanks in advance.
Best,
Da
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Da Zhang

2018-05-24 16:09:59 UTC

Permalink

More details:

The dtb read miss rate stays at 10%. Our workload is a simple sequential
linked list search microbenchmark with fixed heap size at 1MB. Cache size
is varied from 128KB to 2MB.

Post by Da Zhang
Hey guys,
I tried to increase the dtb size (i.e., number of tlb entries) for our
research. However, the stats.txt for the different dtb size
(64,128,256,512,1024,2048,1048576) is practical identical or identical.
For size < 512, the system.switch_cpus.dtb.rdAccesses difference is only
several hundred. For size > 512, the whole stats.txt is identical. I am
working for the X86 architecture. I change the size in X86TLB.py to
increase the dtb size. By checking the config.ini file, I see the size is
set as expected (under system.cpu.dtb). Any clue?
Thanks in advance.
Best,
Da