Re: [gem5-users] Terminating multi-core simulation

[Muhammad Avais]

Dear Haeyoon Cho.,

I am really thankful to you for this help. Actually, i am not very good in
modifying gem5 and this code will be very helpful for me.

I have one more question, is it good idea to normalize the stats with
number of instructions simulated to calculate energy or other things? Does
people use this? Or some other metric to compare energy?

Many thanks for your help,
Best Regards,
Avais

On Thu, May 24, 2018 at 5:45 PM, 조해윤  wrote:

> Dear Avais,
>
> I think running workloads fairly is very important in multi-core
> experiments, because the number of executed instructions of each core can
> be changed depend on each experimental configuration.
> There is a prior work how to experiment fairly on multi-core system; A.
> Hilton et al., "FIESTA: A Sample-Balanced Multi-Program Workload
> Methodology", MoBS, 2009.
> However, implementing this methodology in gem5 is another problem, and I
> couldn't do that.
>
> Alternatively, I modified the gem5 code to terminate by the number of
> total executed instructions of all cores.
> Existing gem5 code can only terminate by the maximum or minimum number of
> executed instructions per core.
> Since LocalSimLoopExitEvent() is called in CPU class in existing gem5
> code, I modified system class code to correct the number of executed
> instructions of all cores and to call LocalSimLoopExitEvent() by system
> class.
> As I think, the most important part is whether you can call
> LocalSimLoopExitEvent() when you want.
> I attach total_sim_exit.patch just for reference.
> I modified followed six files.
> /configs/commom/Simulation.py
> /src/sim/system.hh
> /src/sim/system.cc
> /src/sim/System.py
> /src/cpu/simple/base.hh
> /src/cpu/o3/cpu.cc
> This attached file may not compatible with current gem5 code, because I
> modified code base on stable version of gem5 code.
> Also, this modification is just for restrictive situation that one fast
> forward and one real simulation, and coding style is not good.
>
> If you can modify gem5 code better than me, please let me know.
>
> Best Regards,
> Haeyoon Cho.
>
>
> 2018-05-23 15:55 GMT+09:00 Muhammad Avais :
>
>> Dear All,
>>
>>  I want to measure dynamic energy of L2 cache for multi-core
>> simulations. For this purpose, i measure stats from gem5 like # of hits,  #
>> of misses and # of writebacks.
>>  As, multi-core simulation in gem5 terminates, as soon as, any
>> workload reaches maximum count. Therefore, while comparing different
>> schemes, each scheme terminates after different number of instructions, so
>> stats like  # of hits,  # of misses and # of writebacks are not useful.
>>Is there any  other metric that can be used to compare energy in
>> multicore systems like weighted speed up for performance. Or is it possible
>> that simulation always runs for fixed number of instruction.
>>
>> Many Thanks,
>> Best Regards,
>> Avais
>>
>> ___
>> 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
>
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] RISCV ISA : "C" (compressed) extension supported?

[Marcelo Brandalero]

 Hi Jason, Alec,

Thanks for the fast responses!

I can say I managed to run a lot of benchmarks on O3 and none of them
crashed. I did notice however that their performance on for distinct-width
O3 processors had only minor differences (on x86, the differences were much
more significant).

I ran into this particular issue only today, though, so I can only say it
*seems* *to affect only binaries compíled with C extensions*.

I'll run the tests suggested by both of you and reply here in case I find
anything interesting.

Best regards,


On Thu, May 24, 2018 at 9:29 PM, Marcelo Brandalero 
wrote:

> Hi Jason, Alec,
>
> Thanks for the fast responses!
>
> I can say I managed to run a lot of benchmarks on O3 and none of them
> crashed. I did notice however that their performance on for distinct-width
> O3 processors had only minor differences (on x86, the differences were much
> more significant).
>
> I ran into this particular issue only today, though, so I can only say it
> *seems* *to affect only binaries compíled with C extensions*.
>
> I'll run the tests suggested and reply here in case I find anything
> interesting.
>
> Best regards,
>
> On Thu, May 24, 2018 at 9:06 PM, Alec Roelke  wrote:
>
>> Hi Marcelo,
>>
>> Yes, gem5 does support the C extension (64-bit version only, though).  I
>> don't know what could be causing your particular issue.  I'm not sure
>> advancePC is the issue, though, because all that essentially does is call
>> PCState::advance(), which is inherited unchanged from
>> GenericISA::UPCState.  Try doing as Jason suggests and run your simulation
>> with the Fetch debug flag enabled, and maybe that will shed some light on
>> the issue.
>>
>> -Alec
>>
>> On Thu, May 24, 2018 at 7:20 PM, Jason Lowe-Power 
>> wrote:
>>
>>> Hi Marcelo,
>>>
>>> I'm not sure if RISC-V has been tested with the out of order CPU at all!
>>> I'm happy that at least it doesn't completely fail!
>>>
>>> For you problem of only fetching 1 instruction per cycle... I think it's
>>> going to take some digging. My first guess would be that it could be a
>>> problem with the advancePC() function that's implemented in the RISC-V
>>> decoder (in gem5/arch/riscv), but I don't really have any specific reason
>>> to think that :).
>>>
>>> You could try turning on some debug flags for the O3 CPU. Specifically,
>>> Fetch might be helpful.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Thu, May 24, 2018 at 4:06 PM Marcelo Brandalero <
>>> mbrandal...@inf.ufrgs.br> wrote:
>>>
 Hi all,

 I recently switched from gem5/x86 to gem5/RISCV due to some advantages
 of this ISA.

 I'm getting some weird simulation results and I realized my compiler
 was generating instructions for the compressed RISCV ISA extension (chp
 12 in the user level ISA specification
 ). The weirdness disappears when I
 use *--march* to remove these extensions.

 *So the question is: does gem5/RISCV support this ISA extension? *If
 so, I can share the weird results (maybe I'm missing something) but
 basically a wide-issue O3 processor fetches only max 1 instruction/cycle
 when it should probably be fetching more.

 If it doesn't support then it's all OK, I just find it a bit weird that
 the program executes normally with no warnings whatsoever.

 Best regards,

 --
 Marcelo Brandalero
 PhD Candidate
 Programa de Pós Graduação em Computação
 Universidade Federal do Rio Grande do Sul
 ___
 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
>>
>
>
>
> --
> Marcelo Brandalero
>



-- 
Marcelo Brandalero
PhD Candidate
Programa de Pós Graduação em Computação
Universidade Federal do Rio Grande do Sul
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] RISCV ISA : "C" (compressed) extension supported?

[Alec Roelke]

Hi Marcelo,

Yes, gem5 does support the C extension (64-bit version only, though).  I
don't know what could be causing your particular issue.  I'm not sure
advancePC is the issue, though, because all that essentially does is call
PCState::advance(), which is inherited unchanged from
GenericISA::UPCState.  Try doing as Jason suggests and run your simulation
with the Fetch debug flag enabled, and maybe that will shed some light on
the issue.

-Alec

On Thu, May 24, 2018 at 7:20 PM, Jason Lowe-Power 
wrote:

> Hi Marcelo,
>
> I'm not sure if RISC-V has been tested with the out of order CPU at all!
> I'm happy that at least it doesn't completely fail!
>
> For you problem of only fetching 1 instruction per cycle... I think it's
> going to take some digging. My first guess would be that it could be a
> problem with the advancePC() function that's implemented in the RISC-V
> decoder (in gem5/arch/riscv), but I don't really have any specific reason
> to think that :).
>
> You could try turning on some debug flags for the O3 CPU. Specifically,
> Fetch might be helpful.
>
> Cheers,
> Jason
>
> On Thu, May 24, 2018 at 4:06 PM Marcelo Brandalero <
> mbrandal...@inf.ufrgs.br> wrote:
>
>> Hi all,
>>
>> I recently switched from gem5/x86 to gem5/RISCV due to some advantages of
>> this ISA.
>>
>> I'm getting some weird simulation results and I realized my compiler was
>> generating instructions for the compressed RISCV ISA extension (chp 12
>> in the user level ISA specification ).
>> The weirdness disappears when I use *--march* to remove these extensions.
>>
>> *So the question is: does gem5/RISCV support this ISA extension? *If so,
>> I can share the weird results (maybe I'm missing something) but basically a
>> wide-issue O3 processor fetches only max 1 instruction/cycle when it should
>> probably be fetching more.
>>
>> If it doesn't support then it's all OK, I just find it a bit weird that
>> the program executes normally with no warnings whatsoever.
>>
>> Best regards,
>>
>> --
>> Marcelo Brandalero
>> PhD Candidate
>> Programa de Pós Graduação em Computação
>> Universidade Federal do Rio Grande do Sul
>> ___
>> 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

Re: [gem5-users] RISCV ISA : "C" (compressed) extension supported?

[Jason Lowe-Power]

Hi Marcelo,

I'm not sure if RISC-V has been tested with the out of order CPU at all!
I'm happy that at least it doesn't completely fail!

For you problem of only fetching 1 instruction per cycle... I think it's
going to take some digging. My first guess would be that it could be a
problem with the advancePC() function that's implemented in the RISC-V
decoder (in gem5/arch/riscv), but I don't really have any specific reason
to think that :).

You could try turning on some debug flags for the O3 CPU. Specifically,
Fetch might be helpful.

Cheers,
Jason

On Thu, May 24, 2018 at 4:06 PM Marcelo Brandalero 
wrote:

> Hi all,
>
> I recently switched from gem5/x86 to gem5/RISCV due to some advantages of
> this ISA.
>
> I'm getting some weird simulation results and I realized my compiler was
> generating instructions for the compressed RISCV ISA extension (chp 12 in
> the user level ISA specification ).
> The weirdness disappears when I use *--march* to remove these extensions.
>
> *So the question is: does gem5/RISCV support this ISA extension? *If so,
> I can share the weird results (maybe I'm missing something) but basically a
> wide-issue O3 processor fetches only max 1 instruction/cycle when it should
> probably be fetching more.
>
> If it doesn't support then it's all OK, I just find it a bit weird that
> the program executes normally with no warnings whatsoever.
>
> Best regards,
>
> --
> Marcelo Brandalero
> PhD Candidate
> Programa de Pós Graduação em Computação
> Universidade Federal do Rio Grande do Sul
> ___
> 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

[gem5-users] RISCV ISA : "C" (compressed) extension supported?

[Marcelo Brandalero]

Hi all,

I recently switched from gem5/x86 to gem5/RISCV due to some advantages of
this ISA.

I'm getting some weird simulation results and I realized my compiler was
generating instructions for the compressed RISCV ISA extension (chp 12 in
the user level ISA specification ). The
weirdness disappears when I use *--march* to remove these extensions.

*So the question is: does gem5/RISCV support this ISA extension? *If so, I
can share the weird results (maybe I'm missing something) but basically a
wide-issue O3 processor fetches only max 1 instruction/cycle when it should
probably be fetching more.

If it doesn't support then it's all OK, I just find it a bit weird that the
program executes normally with no warnings whatsoever.

Best regards,

-- 
Marcelo Brandalero
PhD Candidate
Programa de Pós Graduação em Computação
Universidade Federal do Rio Grande do Sul
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

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

[Da Zhang]

I am using FS mode.

On Thu, May 24, 2018 at 12:00 PM, Jason Lowe-Power 
wrote:

> 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
>
> On Thu, May 24, 2018 at 8:45 AM Da Zhang  wrote:
>
>> 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
>> 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
>
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

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

[Da Zhang]

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.

On Thu, May 24, 2018 at 11:44 AM, Da Zhang  wrote:

> 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
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

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

[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

On Thu, May 24, 2018 at 8:45 AM Da Zhang  wrote:

> 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
> 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

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

[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
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] x86 floating point instruction

[Jason Lowe-Power]

Hi Tariq,

It wold be great if you could review Gabe's patch on gerrit. Since it works
for you, giving it a +1 or a +2 would be appropriate.

Cheers,
Jason

On Wed, May 23, 2018 at 5:56 PM Tariq Azmy  wrote:

> Thanks Gabe. Yeah it does not impact the program but it's just that the
> statistic is incorrect.
>
> By the way, I applied the patch and stats now shows correct micro-ops
> entries.
>
> Appreciate your help. Thanks again
>
> On Wed, May 23, 2018 at 6:51 PM, Gabe Black  wrote:
>
>> Yep, those microops aren't given a operand class, and so the isa parser
>> is guessing and making the FloatAddOp. I haven't really tested this beyond
>> making sure it compiles, but here's a patch that might get this working for
>> you.
>>
>> https://gem5-review.googlesource.com/c/public/gem5/+/10541
>>
>> Gabe
>>
>> On Wed, May 23, 2018 at 4:13 PM, Gabe Black  wrote:
>>
>>> I'm confident they aren't implemented with floating point add. It's
>>> likely either that the microops are misclassified, or they're unimplemented
>>> and printing a warning, but the fact that they don't actually do any math
>>> isn't impacting your program for whatever reason. I'll take a quick look.
>>>
>>> Gabe
>>>
>>> On Wed, May 23, 2018 at 2:07 PM, Tariq Azmy 
>>> wrote:
>>>
 Hi,

 I wrote simple code that does simple floating point multiplication and
 division operation and from the assembly, I can see there are MULSS and
 DIVSS instructions. But after I ran the simulation on gem5 and looked at
 the stat.txt, I can only see the entries in
 system.cpu.iq.FU_type_0::FloatAdd, where as the entries in FloatMul and
 FloatDiv remains 0.

 If I understand correctly, these stats refer to the micro-ops. Does
 that mean the MULSS and DIVSS instruction are broken down and executed with
 floating point Add?

 Thanks


 ___
 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
>>
>
> ___
> 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

Re: [gem5-users] free coud

[Ciro Santilli]

Why don't you ask your university / supervisor for some more
resources? I think that is your best bet.

On Mon, May 21, 2018 at 6:57 PM, commerce _com  wrote:
> Hi Ciro;
> I am a doctoral student in first year computer science, I work on armv8
> architecture on the big.LITTLE mode, the goal of my work is that developed a
> new architecture to optimize the execution time and the consumption of
> energy, for the moment i'm running the linux kernel on an armv8 architecture
> in big.LITTLE mode but i found a simulation time problem, so that's why i
> need a cloud to do the sumulation quickly, please if you have any idea help
> me and thank you.
>
> 2018-05-21 16:24 GMT+02:00 Ciro Santilli :
>>
>> Are you affiliated with an university or enterprise?
>>
>> What is your end goal in using gem5? Does it justify the cloud
>> investment in your project?
>>
>> How long does your build / Linux kernel boot take? Here are some
>> references:
>> https://github.com/cirosantilli/linux-kernel-module-cheat/tree/58face41ac849d029536a3c0dba33c8d68c30afa#benchmark-this-repo
>>
>> On Mon, May 21, 2018 at 3:19 PM, commerce _com 
>> wrote:
>> > hi all;
>> > i need a free cloud to do the simulation with gem5, please is there?
>> > because
>> > i do not have a powerful pc.
>> >
>> > thanks advance;
>> >
>> > ___
>> > 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
>
>
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] parsec3.0 compilation by aarch64-linux-gnu-gcc cross compiler.

[Ciro Santilli]

Hi commerce, I'm maintaining a fork of parsec at:
https://github.com/cirosantilli/parsec-benchmark

I don't have all benchmarks working, but I documented how everything
fails, and if you get something working, please send a pull request
there as well.

On Wed, May 23, 2018 at 12:51 PM, commerce _com
 wrote:
> I installed aarch64-linux-gnu-gcc cross compiler in my ubuntu system to
> compile parsec3.0, and I typed the following commands:
>
> source ./env.sh
> parsecmgmt -a build -c gcc-hooks -p blackscholes
>
> and I found this compilation result:
>
> [PARSEC] Packages to build:  parsec.blackscholes
>
> [PARSEC] [== Building package parsec.blackscholes [1] ==]
> [PARSEC] [-- Analyzing package parsec.blackscholes --]
> [PARSEC] Package parsec.blackscholes already exists, proceeding.
> [PARSEC]
> [PARSEC] BIBLIOGRAPHY
> [PARSEC]
> [PARSEC] [1] Bienia. Benchmarking Modern Multiprocessors. Ph.D. Thesis,
> 2011.
> [PARSEC]
> [PARSEC] Done.
>
> nb:I found the binarie in the following path:
>
> /parsec-3.0/pkgs/apps/blackscholes/inst/amd64-linux.gcc-hooks/bin/blackscholes
>
> please is this method true?
>
>
> thanks.
> commerce.
>
>
>
> ___
> 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

Re: [gem5-users] Terminating multi-core simulation

[조해윤]

Dear Avais,

I think running workloads fairly is very important in multi-core
experiments, because the number of executed instructions of each core can
be changed depend on each experimental configuration.
There is a prior work how to experiment fairly on multi-core system; A.
Hilton et al., "FIESTA: A Sample-Balanced Multi-Program Workload
Methodology", MoBS, 2009.
However, implementing this methodology in gem5 is another problem, and I
couldn't do that.

Alternatively, I modified the gem5 code to terminate by the number of total
executed instructions of all cores.
Existing gem5 code can only terminate by the maximum or minimum number of
executed instructions per core.
Since LocalSimLoopExitEvent() is called in CPU class in existing gem5 code,
I modified system class code to correct the number of executed instructions
of all cores and to call LocalSimLoopExitEvent() by system class.
As I think, the most important part is whether you can call
LocalSimLoopExitEvent() when you want.
I attach total_sim_exit.patch just for reference.
I modified followed six files.
/configs/commom/Simulation.py
/src/sim/system.hh
/src/sim/system.cc
/src/sim/System.py
/src/cpu/simple/base.hh
/src/cpu/o3/cpu.cc
This attached file may not compatible with current gem5 code, because I
modified code base on stable version of gem5 code.
Also, this modification is just for restrictive situation that one fast
forward and one real simulation, and coding style is not good.

If you can modify gem5 code better than me, please let me know.

Best Regards,
Haeyoon Cho.


2018-05-23 15:55 GMT+09:00 Muhammad Avais :

> Dear All,
>
>  I want to measure dynamic energy of L2 cache for multi-core
> simulations. For this purpose, i measure stats from gem5 like # of hits,  #
> of misses and # of writebacks.
>  As, multi-core simulation in gem5 terminates, as soon as, any
> workload reaches maximum count. Therefore, while comparing different
> schemes, each scheme terminates after different number of instructions, so
> stats like  # of hits,  # of misses and # of writebacks are not useful.
>Is there any  other metric that can be used to compare energy in
> multicore systems like weighted speed up for performance. Or is it possible
> that simulation always runs for fixed number of instruction.
>
> Many Thanks,
> Best Regards,
> Avais
>
> ___
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>


tatal_sim_exit.patch
Description: Binary data
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users