Re: [gem5-users] How many cpu does the x86 vmlinux SMP kernel support?

[Chao Zhang via gem5-users]

Hi all,

I changed to the kernel provided by UT Texas. And it can support at least 32 
cores.
Thanks a lot.

Chao
On Aug 28, 2014, at 10:09 PM, Chao Zhang via gem5-users  
wrote:

> Hi Andreas,
> 
> I tried the alpha first. I found I have set up this ISA and I rebuild it for 
> this test.
> It can only support 4 timing simple alpha cores. And when I set the number of 
> cpu to 5, the m5 terminal output indicates CPU #4 (which is the 5th cpu) is 
> stuck. 
> So can I say it can only support 4 cpu? What should I do if I want to support 
> more (like 16) cpus in classical memory system with alpha timing core?
>  
> Thanks!
> 
> On Aug 27, 2014, at 3:48 PM, Andreas Hansson  wrote:
> 
>> Hi Chao,
>> 
>> Unfortunately the classic memory system does not support X86 atomic RMW 
>> operations. This is why it works in atomic and not in timing.
>> 
>> You options are:
>> 1) implement a fix and do everyone a big favour (I vote for this one)
>> 2) take the hit in simulation speed and switch to Ruby and stick to timing 
>> mode
>> 3) use another ISA, e.g. ARM :-), that does not have this problem
>> 
>> I hope that explains it.
>> 
>> Andreas
>> 
>> From: Chao Zhang via gem5-users 
>> Reply-To: Chao Zhang , gem5 users mailing list 
>> 
>> Date: Wednesday, 27 August 2014 07:47
>> To: gem5 users mailing list 
>> Subject: [gem5-users] How many cpu does the x86 vmlinux SMP kernel support?
>> 
>> Dear all,
>> 
>> I’m currently working on x86 FS on classical memory system to simulate cache 
>> system. But I found the kernel booting just hangs before loading benchmark 
>> script. It does not work when I set 3 or more x86 timing simple cpus, but it 
>> does work when I set them as atomic cores. And it also works when I set cpu 
>> number to 1. The gem5 change set version is 10242, the kernel is the SMP 
>> version from gem5 website (x86_64-vmlinux-2.6.28.4-smp), and I use default 
>> fs.py configuration. 
>> 
>> So I want to know how many x86 timing cores does this SMP kernel support? Or 
>> is this a memory system problem? 
>> 
>> Chao Zhang
>> Peking University
>> 
>> 
>> 
>> 
>> 
>> 
>> -- IMPORTANT NOTICE: The contents of this email and any attachments are 
>> confidential and may also be privileged. If you are not the intended 
>> recipient, please notify the sender immediately and do not disclose the 
>> contents to any other person, use it for any purpose, or store or copy the 
>> information in any medium. Thank you.
>> 
>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
>> Registered in England & Wales, Company No: 2557590
>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
>> Registered in England & Wales, Company No: 2548782
> 
> ___
> 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] Big executed instruction difference between X86 atomic adn X86 O3

[Mitch Hayenga via gem5-users]

Hi,

As far as I know those are the only instructions that call suspend() on a
thread context in gem5 for the x86 ISA.  This is all I found from grepping
the src/arch/x86 directories.  But I'm not an expert on the x86 ISA, I just
touched this code because it was breaking regression tests.

The "459500" ticks isn't really all that large terms of time.  Assuming
you're running a 2GHz core (this number is in pico seconds), thats only 919
cycles.  This could easily be explained by having to walk a page
table, branch mispredicts, etc when entering a new region of code. The
atomic CPU wouldn't have to pay any of that time cost (since memory is
accessed instantaneously on it and there are no mispredicts).  It also
could be that the last instruction was the MicroHalt, and it only took 900
cycles for the core to be woken up.  No way to know without looking at what
actually happened.

How are you measuring the divergence to know things are going wrong in
simulation?  The timings/code scheduling done by the OS can be very
different for the Atomic and Timing-focused cores. Basically, different
sequences of committed instructions from atomic and o3 are fine, as long as
the numbers are not completely out of line.




On Thu, Aug 28, 2014 at 5:49 AM, Zi Yan via gem5-users 
wrote:

> Hi Andreas,
>
> I already flag "MicroHalt" as "IsQuiesce" in my last running. And I am not
> using m5ops, so first part of your patch should not affect my running.
>
> Therefore, as I mentioned in my last email, the waiting for
> apic_timer_interrupt behavior still happens for certain instructions.
>
> 1) Is every x86 quiesce marco instruction properly decoded with
> "MicroHalt" microop in gem5?
>
> 2) Does Intel ISA manual say anything about quiesce instruction? So that
> I can find a reference and help check all quiesce instructions in X86.
>
> Thanks.
>
> --
> Best Regards
> Yan Zi
>
> On 28 Aug 2014, at 3:39, Andreas Hansson wrote:
>
> > Hi Yan,
> >
> > Check out: http://reviews.gem5.org/r/2369/
> >
> > Perhaps the problem you are struggling with is even more complex, but at
> > least the patches on the review board should fix up a few issues.
> >
> > Andreas
> >
> > On 28/08/2014 03:27, "Zi Yan via gem5-users" 
> wrote:
> >
> >> Hi Mitch,
> >>
> >> After I applied two patches and IsQuiesce modification, O3 CPU keeps
> >> in the same track as atomic CPU longer than before. But
> >> apic_timer_interrupt
> >> function comes out again in O3 CPU. It used to come out after about
> >> 500,000
> >> instructions, now it comes out after about 990,000 instructions.
> >>
> >> In addition, I dump out tick numbers as well as PCs, so that I find out
> >> there is a 459500 ticks gap between last committed user instruction and
> >> first instruction in apic_timer_interrupt function. This confirms that
> >> the last user instruction sits in commit until timer interrupt happens.
> >> Am I right about this?
> >>
> >> Next step, I think I need to label all x86 quiesce instructions.
> >> Do you have a list of those instructions? Or does somewhere in
> >> Intel manual tell me about this?
> >>
> >> Thanks.
> >>
> >> --
> >> Best Regards
> >> Yan Zi
> >>
> >> On 27 Aug 2014, at 15:59, Mitch Hayenga wrote:
> >>
> >>> Yep, that should do it.
> >>>
> >>>
> >>> On Wed, Aug 27, 2014 at 2:57 PM, Zi Yan  wrote:
> >>>
>  Thanks.
> 
>  I will apply 1, and 2 patches.
> 
>  For 3, I need to change the file
>  src/arch/x86/isa/microops/specop.isa:66
>  from
>  setFlags | (ULL(1) << StaticInst::IsNonSpeculative),
>  to
>  setFlags | (ULL(1) << StaticInst::IsNonSpeculative) | (ULL(1) <<
>  StaticInst::IsQuiesce),
> 
>  Am I doing the right thing to tag "MicroHalt" instruction as
>  "IsQuiesce"?
> 
>  BTW, what I did to boot linux is to install gentoo inside QEMU,
>  then use x86KvmCPU to boot up, then take checkpoints and run from
>  checkpoints.
> 
>  I will report whether this works or not.
> 
>  Thanks.
> 
>  --
>  Best Regards
>  Yan Zi
> 
>  On 27 Aug 2014, at 15:44, Mitch Hayenga wrote:
> 
> > There are probably three main patches that could help.  The fact you
> > mention the timer interrupt makes me think Andreas is right and these
>  might
> > solve your issue.
> >
> > 1. http://reviews.gem5.org/r/2363/  - o3 is supposed to stop
> fetching
> > instructions immediately once a quiesce instruction is encountered,
> > some
> > managed to sneak by.  Quiesce is used for things like sleeping until
> > an
> > interrupt occurs, etc.  Without this patch, we experienced the case
> > where
> > o3 state would get corrupted and an instruction would sit at commit
> > until
> > the next timer interrupt happened.  At which point taking the
> > interrupt
> > would clear the state and execution would continue (until this same
> > bug
> > happened again).
> >
> > 2. http://reviews.gem5.org/

Re: [gem5-users] ARMv8 Client-Server configuration

[Ali Saidi via gem5-users]

You should be able to get a new working kernel with PCIe support for AArch64 
like the following, however you’ll need all the patches that Andreas just 
mentioned in an email to gem5-dev as committed next week.

wget 
"http://www.linux-arm.org/git?p=linux-aarch64-gem5.git;a=snapshot;h=400390889828685d432d38406cbd9c7afceeaa15;sf=tgz";
 -O linux-aarch64-gem5.tgz
tar zxvf linux-aarch64-gem5.tgz
cd linux-aarch64-gem5-4003908
make ARCH=arm64 CROSS_COMPILE=aarch64-none-elf- gem5_defconfig
make ARCH=arm64 CROSS_COMPILE=aarch64-none-elf- -j4

Thanks,
Ali



From: Ali Saidi via gem5-users mailto:gem5-users@gem5.org>>
Reply-To: Ali Saidi mailto:sa...@umich.edu>>, gem5 users 
mailing list mailto:gem5-users@gem5.org>>
Date: Saturday, August 23, 2014 at 2:21 PM
To: Ivan Stalev mailto:ids...@psu.edu>>, gem5 users mailing 
list mailto:gem5-users@gem5.org>>
Subject: Re: [gem5-users] ARMv8 Client-Server configuration

You’re not going to have any support for PCIe device with that kernel. We’re 
working on the last bit of debugging and polishing around a kernel that will 
support it — I intended to have it out 2 weeks ago, but we’re still diligently 
working and it should be out in the next couple of days.

Ali




On Aug 20, 2014, at 10:36 AM, Ivan Stalev 
mailto:ids...@psu.edu>> wrote:

Edit: I was using my own compiled kernel. I am now using the default kernel, 
vmlinux-3.14-aarch64-vexpress-emm64, and it appears not to crash. I will go 
ahead and test it out.


On Wed, Aug 20, 2014 at 11:19 AM, Ivan Stalev 
mailto:ids...@psu.edu>> wrote:
Hi Andreas,

No problem, I figured it wasn't the 80 char README file patch :)

I applied the 7 patches you posted this morning, but now when I run in dual 
mode, gem5 crashes with this:

panic: M5 panic instruction called at pc=0xffc8a024.
 @ tick 58408160
[execute:build/ARM/arch/arm/generated/exec-ns.cc.inc, line 241403]

The GDB backtrace from gem5.debug suggests that execution is somehow killed 
from a manually inserted breakpoint.

This is also after I had to hardcode the DTB file name for the drivesys in 
/src/arch/arm/linux/system.cc since it was not picking it up 
from the command line...

warn: Kernel supports device tree, but no DTB file specified
fatal: Expected a single ATAG memory entry but got 3
 @ tick 58402784
[initState:build/ARM/arch/arm/linux/system.cc, line 202]

Can you share how you tested the client-server configuration?

Thank you,

Ivan




On Wed, Aug 20, 2014 at 4:45 AM, Andreas Hansson 
mailto:andreas.hans...@arm.com>> wrote:
Hi Ivan,

Just following up on this one. I posted the patches yesterday morning, but 
forgot to “Publish” then. Sorry about the misunderstanding. They are all there 
now.

Andreas

From: Andreas Hansson via gem5-users 
mailto:gem5-users@gem5.org>>
Reply-To: Andreas Hansson 
mailto:andreas.hans...@arm.com>>, gem5 users mailing 
list mailto:gem5-users@gem5.org>>
Date: Tuesday, 19 August 2014 18:48
To: Ivan Stalev mailto:ids...@psu.edu>>, gem5 users mailing 
list mailto:gem5-users@gem5.org>>, Ali Saidi 
mailto:sa...@umich.edu>>

Subject: Re: [gem5-users] ARMv8 Client-Server configuration

Hi Ivan,

The patches are on the review board as of this morning (UK time).

Comments are welcome as always.

Andreas

From: Ivan Stalev via gem5-users 
mailto:gem5-users@gem5.org>>
Reply-To: Ivan Stalev mailto:ids...@psu.edu>>, gem5 users 
mailing list mailto:gem5-users@gem5.org>>
Date: Tuesday, 19 August 2014 18:44
To: Ali Saidi mailto:sa...@umich.edu>>
Cc: gem5 users mailing list mailto:gem5-users@gem5.org>>
Subject: Re: [gem5-users] ARMv8 Client-Server configuration

Hi Ali,

Have you had the chance to look at the issue or have some suggestions as to 
which source files to look at?

Thanks,

Ivan


On Fri, Aug 8, 2014 at 8:34 PM, Ali Saidi 
mailto:sa...@umich.edu>> wrote:
Hi Ivan,

The kernel that you’re using and the currently gem5 don’t support pci devices 
with arm64. I hope to remedy this within a week.

Thanks,
Ali

On Aug 6, 2014, at 3:42 PM, Ivan Stalev via gem5-users 
mailto:gem5-users@gem5.org>> wrote:

> Hi everyone,
>
> I am trying to run a client-server setup using arm64. I am using the (latest) 
> linaro kernel (3.16) and disk image suggested on the GEM5 downloads page. 
> Simply building the kernel with defconfig (as recommended in the README) does 
> not seem to setup the ethernet drivers. Running "ifconfig -a" only yields the 
> loopback device/interface.
>
> I then opened up the .config (generated by defconfig) using menuconfig and 
> enabled all the settings related to ethernet and re-built the kernel. After 
> booting, "ifconfig -a" results in this:
>
> bond0 Link encap:Ethernet  HWaddr CA:FB:D0:02:D0:7E
>   BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
> dummy0  

Re: [gem5-users] How to add shared nonblocking L3 cache in gem5?

[Prathap Kolakkampadath via gem5-users]

In that case whether the MSHR's would be shared between 2 L2 Caches or can
have separate MSHR for each L2 cache?

Thanks.


On Thu, Aug 28, 2014 at 11:52 AM, Andreas Hansson 
wrote:

>  Hi Prathap,
>
>  Definitely. The gem5 memory system let’s you build any tree-topology you
> like, even unbalanced (L2 for one core, and no L2 for another etc, 2 core
> for one L2 and a single core for the next). Just instantiate an L2 per
> core, connect it with a CoherentBus to the L1s of that core, and then use a
> CoherentBus on the memory-side of the L2 to “merge” the tree into the L3
> (or use split L3’s as well).
>
>  If you’ve got pydot installed gem5 generates a PDF/SVG showing the
> system layout to visually ensure you’ve accomplished what you intended.
>
>  Andreas
>
>   From: Prathap Kolakkampadath 
> Date: Thursday, 28 August 2014 17:47
> To: Andreas Hansson 
> Cc: gem5 users mailing list 
> Subject: Re: [gem5-users] How to add shared nonblocking L3 cache in gem5?
>
>  Thanks Andreas. I have one more question regarding cache. Is it posible
> to create a system with multiple L2 caches each private to a specific core?
>
>
> On Wed, Aug 27, 2014 at 2:51 AM, Andreas Hansson 
> wrote:
>
>>  Hi Prathap,
>>
>>  You can easily create a subclass of the BaseCache and give it suitable
>> parameters for an L3. This should be fairly straight forward and also easy
>> to instantiate in the Python scripts (e.g. fs.py)
>>
>>  Andreas
>>
>>   From: Prathap Kolakkampadath via gem5-users 
>> Reply-To: Prathap Kolakkampadath , gem5 users
>> mailing list 
>> Date: Wednesday, 27 August 2014 05:25
>> To: gem5 users mailing list 
>> Subject: [gem5-users] How to add shared nonblocking L3 cache in gem5?
>>
>>  Hi Users,
>>
>>
>>  I am new to gem5 and I want to add nonblacking shared Last level
>> cache(L3). I could see L3 cache options in Options.py with default values
>> set. However there is no entry for L3 in Caches.py and CacheConfig.py.
>>
>>  So extending Cache.py and CacheConfig.py would be enough to create L3
>> cache?
>>
>>
>>  Thanks,
>> Prathap
>>
>>
>> -- IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>>
>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>> Registered in England & Wales, Company No: 2557590
>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>> Registered in England & Wales, Company No: 2548782
>>
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No: 2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No: 2548782
>
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] How to add shared nonblocking L3 cache in gem5?

[Andreas Hansson via gem5-users]

Hi Prathap,

Definitely. The gem5 memory system let’s you build any tree-topology you like, 
even unbalanced (L2 for one core, and no L2 for another etc, 2 core for one L2 
and a single core for the next). Just instantiate an L2 per core, connect it 
with a CoherentBus to the L1s of that core, and then use a CoherentBus on the 
memory-side of the L2 to “merge” the tree into the L3 (or use split L3’s as 
well).

If you’ve got pydot installed gem5 generates a PDF/SVG showing the system 
layout to visually ensure you’ve accomplished what you intended.

Andreas

From: Prathap Kolakkampadath mailto:kvprat...@gmail.com>>
Date: Thursday, 28 August 2014 17:47
To: Andreas Hansson mailto:andreas.hans...@arm.com>>
Cc: gem5 users mailing list mailto:gem5-users@gem5.org>>
Subject: Re: [gem5-users] How to add shared nonblocking L3 cache in gem5?

Thanks Andreas. I have one more question regarding cache. Is it posible to 
create a system with multiple L2 caches each private to a specific core?


On Wed, Aug 27, 2014 at 2:51 AM, Andreas Hansson 
mailto:andreas.hans...@arm.com>> wrote:
Hi Prathap,

You can easily create a subclass of the BaseCache and give it suitable 
parameters for an L3. This should be fairly straight forward and also easy to 
instantiate in the Python scripts (e.g. fs.py)

Andreas

From: Prathap Kolakkampadath via gem5-users 
mailto:gem5-users@gem5.org>>
Reply-To: Prathap Kolakkampadath 
mailto:kvprat...@gmail.com>>, gem5 users mailing list 
mailto:gem5-users@gem5.org>>
Date: Wednesday, 27 August 2014 05:25
To: gem5 users mailing list mailto:gem5-users@gem5.org>>
Subject: [gem5-users] How to add shared nonblocking L3 cache in gem5?

Hi Users,


I am new to gem5 and I want to add nonblacking shared Last level cache(L3). I 
could see L3 cache options in Options.py with default values set. However there 
is no entry for L3 in Caches.py and CacheConfig.py.

So extending Cache.py and CacheConfig.py would be enough to create L3 cache?


Thanks,
Prathap


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No: 2548782


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No: 2548782___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] How to add shared nonblocking L3 cache in gem5?

[Prathap Kolakkampadath via gem5-users]

Thanks Andreas. I have one more question regarding cache. Is it posible to
create a system with multiple L2 caches each private to a specific core?


On Wed, Aug 27, 2014 at 2:51 AM, Andreas Hansson 
wrote:

>  Hi Prathap,
>
>  You can easily create a subclass of the BaseCache and give it suitable
> parameters for an L3. This should be fairly straight forward and also easy
> to instantiate in the Python scripts (e.g. fs.py)
>
>  Andreas
>
>   From: Prathap Kolakkampadath via gem5-users 
> Reply-To: Prathap Kolakkampadath , gem5 users
> mailing list 
> Date: Wednesday, 27 August 2014 05:25
> To: gem5 users mailing list 
> Subject: [gem5-users] How to add shared nonblocking L3 cache in gem5?
>
>  Hi Users,
>
>
>  I am new to gem5 and I want to add nonblacking shared Last level
> cache(L3). I could see L3 cache options in Options.py with default values
> set. However there is no entry for L3 in Caches.py and CacheConfig.py.
>
>  So extending Cache.py and CacheConfig.py would be enough to create L3
> cache?
>
>
>  Thanks,
> Prathap
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No: 2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No: 2548782
>
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] How many cpu does the x86 vmlinux SMP kernel support?

[Chao Zhang via gem5-users]

Hi Andreas,

I tried the alpha first. I found I have set up this ISA and I rebuild it for 
this test.
It can only support 4 timing simple alpha cores. And when I set the number of 
cpu to 5, the m5 terminal output indicates CPU #4 (which is the 5th cpu) is 
stuck. 
So can I say it can only support 4 cpu? What should I do if I want to support 
more (like 16) cpus in classical memory system with alpha timing core?
 
Thanks!

On Aug 27, 2014, at 3:48 PM, Andreas Hansson  wrote:

> Hi Chao,
> 
> Unfortunately the classic memory system does not support X86 atomic RMW 
> operations. This is why it works in atomic and not in timing.
> 
> You options are:
> 1) implement a fix and do everyone a big favour (I vote for this one)
> 2) take the hit in simulation speed and switch to Ruby and stick to timing 
> mode
> 3) use another ISA, e.g. ARM :-), that does not have this problem
> 
> I hope that explains it.
> 
> Andreas
> 
> From: Chao Zhang via gem5-users 
> Reply-To: Chao Zhang , gem5 users mailing list 
> 
> Date: Wednesday, 27 August 2014 07:47
> To: gem5 users mailing list 
> Subject: [gem5-users] How many cpu does the x86 vmlinux SMP kernel support?
> 
> Dear all,
> 
> I’m currently working on x86 FS on classical memory system to simulate cache 
> system. But I found the kernel booting just hangs before loading benchmark 
> script. It does not work when I set 3 or more x86 timing simple cpus, but it 
> does work when I set them as atomic cores. And it also works when I set cpu 
> number to 1. The gem5 change set version is 10242, the kernel is the SMP 
> version from gem5 website (x86_64-vmlinux-2.6.28.4-smp), and I use default 
> fs.py configuration. 
> 
> So I want to know how many x86 timing cores does this SMP kernel support? Or 
> is this a memory system problem? 
> 
> Chao Zhang
> Peking University
> 
> 
> 
> 
> 
> 
> -- IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> 
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
> Registered in England & Wales, Company No: 2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
> Registered in England & Wales, Company No: 2548782

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

Re: [gem5-users] Big executed instruction difference between X86 atomic adn X86 O3

[Zi Yan via gem5-users]

Hi Andreas,

I already flag "MicroHalt" as "IsQuiesce" in my last running. And I am not 
using m5ops, so first part of your patch should not affect my running.

Therefore, as I mentioned in my last email, the waiting for 
apic_timer_interrupt behavior still happens for certain instructions.

1) Is every x86 quiesce marco instruction properly decoded with 
"MicroHalt" microop in gem5?

2) Does Intel ISA manual say anything about quiesce instruction? So that
I can find a reference and help check all quiesce instructions in X86.

Thanks.

--
Best Regards
Yan Zi

On 28 Aug 2014, at 3:39, Andreas Hansson wrote:

> Hi Yan,
>
> Check out: http://reviews.gem5.org/r/2369/
>
> Perhaps the problem you are struggling with is even more complex, but at
> least the patches on the review board should fix up a few issues.
>
> Andreas
>
> On 28/08/2014 03:27, "Zi Yan via gem5-users"  wrote:
>
>> Hi Mitch,
>>
>> After I applied two patches and IsQuiesce modification, O3 CPU keeps
>> in the same track as atomic CPU longer than before. But
>> apic_timer_interrupt
>> function comes out again in O3 CPU. It used to come out after about
>> 500,000
>> instructions, now it comes out after about 990,000 instructions.
>>
>> In addition, I dump out tick numbers as well as PCs, so that I find out
>> there is a 459500 ticks gap between last committed user instruction and
>> first instruction in apic_timer_interrupt function. This confirms that
>> the last user instruction sits in commit until timer interrupt happens.
>> Am I right about this?
>>
>> Next step, I think I need to label all x86 quiesce instructions.
>> Do you have a list of those instructions? Or does somewhere in
>> Intel manual tell me about this?
>>
>> Thanks.
>>
>> --
>> Best Regards
>> Yan Zi
>>
>> On 27 Aug 2014, at 15:59, Mitch Hayenga wrote:
>>
>>> Yep, that should do it.
>>>
>>>
>>> On Wed, Aug 27, 2014 at 2:57 PM, Zi Yan  wrote:
>>>
 Thanks.

 I will apply 1, and 2 patches.

 For 3, I need to change the file
 src/arch/x86/isa/microops/specop.isa:66
 from
 setFlags | (ULL(1) << StaticInst::IsNonSpeculative),
 to
 setFlags | (ULL(1) << StaticInst::IsNonSpeculative) | (ULL(1) <<
 StaticInst::IsQuiesce),

 Am I doing the right thing to tag "MicroHalt" instruction as
 "IsQuiesce"?

 BTW, what I did to boot linux is to install gentoo inside QEMU,
 then use x86KvmCPU to boot up, then take checkpoints and run from
 checkpoints.

 I will report whether this works or not.

 Thanks.

 --
 Best Regards
 Yan Zi

 On 27 Aug 2014, at 15:44, Mitch Hayenga wrote:

> There are probably three main patches that could help.  The fact you
> mention the timer interrupt makes me think Andreas is right and these
 might
> solve your issue.
>
> 1. http://reviews.gem5.org/r/2363/  - o3 is supposed to stop fetching
> instructions immediately once a quiesce instruction is encountered,
> some
> managed to sneak by.  Quiesce is used for things like sleeping until
> an
> interrupt occurs, etc.  Without this patch, we experienced the case
> where
> o3 state would get corrupted and an instruction would sit at commit
> until
> the next timer interrupt happened.  At which point taking the
> interrupt
> would clear the state and execution would continue (until this same
> bug
> happened again).
>
> 2. http://reviews.gem5.org/r/2367/  - If o3 was being drained while an
> interrupt occurred on x86, it could deadlock.
>
> 3. I believe this last patch will be posted in a day or two.  x86
 currently
> does not tag any instruction that suspends() the CPU as a "quiesce".
 This
> is required by o3 to properly operate, but not by the Atomic CPU.
> This
> makes the issue in #1 far more likely to occur.  It's pretty amazing
> that
> x86 booted linux at all on o3 without this.  I believe this patch
> will be
> posted shortly, but otherwise you could just tag the "MicroHalt"
> instruction as "IsQuiesce" yourself.
>
> So a combination of those things (mainly the last one) could lead to
> what
> you are seeing.
>
>
> On Wed, Aug 27, 2014 at 12:59 PM, Zi Yan via gem5-users <
 gem5-users@gem5.org
>> wrote:
>
>> OK. Could you please tell me which patches are there? In the
>> review board there are quite a lot of new patches waiting
>> for review.
>>
>> I can apply those patches myself and do a quick test.
>>
>> Thanks.
>>
>> --
>> Best Regards
>> Yan Zi
>>
>> On 27 Aug 2014, at 13:56, Andreas Hansson wrote:
>>
>>> Hi Yan,
>>>
>>> I would suspect this is due to a bug in the X86 O3 CPU. There have
>>> been
>>> quite a few fixes posted on the review board for similar issues. I
>>> hope
>> to
>>> have these committed in the next week or so.
>>

Re: [gem5-users] Debug flag DRAMPower

[Andreas Hansson via gem5-users]

Hi Hussain,

Write should work just fine. Are you sure there are actually any writes coming 
from the L2?

Andreas

From: Hussain Asad via gem5-users 
mailto:gem5-users@gem5.org>>
Reply-To: Hussain Asad 
mailto:x7xcloudstr...@gmail.com>>, gem5 users mailing 
list mailto:gem5-users@gem5.org>>
Date: Thursday, 28 August 2014 07:01
To: "gem5-users@gem5.org" 
mailto:gem5-users@gem5.org>>
Subject: [gem5-users] Debug flag DRAMPower

Hi,

I have been running with the debug flag option for DRAMPower for memory power 
consumption however I noticed that there are no writes in any of the traces 
generated no matter the CPU type, seems write commands does not get registered 
from mem_cntrls.

Best Regards
Hussain

-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No: 2548782___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] Big executed instruction difference between X86 atomic adn X86 O3

[Andreas Hansson via gem5-users]

Hi Yan,

Check out: http://reviews.gem5.org/r/2369/

Perhaps the problem you are struggling with is even more complex, but at
least the patches on the review board should fix up a few issues.

Andreas

On 28/08/2014 03:27, "Zi Yan via gem5-users"  wrote:

>Hi Mitch,
>
>After I applied two patches and IsQuiesce modification, O3 CPU keeps
>in the same track as atomic CPU longer than before. But
>apic_timer_interrupt
>function comes out again in O3 CPU. It used to come out after about
>500,000
>instructions, now it comes out after about 990,000 instructions.
>
>In addition, I dump out tick numbers as well as PCs, so that I find out
>there is a 459500 ticks gap between last committed user instruction and
>first instruction in apic_timer_interrupt function. This confirms that
>the last user instruction sits in commit until timer interrupt happens.
>Am I right about this?
>
>Next step, I think I need to label all x86 quiesce instructions.
>Do you have a list of those instructions? Or does somewhere in
>Intel manual tell me about this?
>
>Thanks.
>
>--
>Best Regards
>Yan Zi
>
>On 27 Aug 2014, at 15:59, Mitch Hayenga wrote:
>
>> Yep, that should do it.
>>
>>
>> On Wed, Aug 27, 2014 at 2:57 PM, Zi Yan  wrote:
>>
>>> Thanks.
>>>
>>> I will apply 1, and 2 patches.
>>>
>>> For 3, I need to change the file
>>>src/arch/x86/isa/microops/specop.isa:66
>>> from
>>> setFlags | (ULL(1) << StaticInst::IsNonSpeculative),
>>> to
>>> setFlags | (ULL(1) << StaticInst::IsNonSpeculative) | (ULL(1) <<
>>> StaticInst::IsQuiesce),
>>>
>>> Am I doing the right thing to tag "MicroHalt" instruction as
>>>"IsQuiesce"?
>>>
>>> BTW, what I did to boot linux is to install gentoo inside QEMU,
>>> then use x86KvmCPU to boot up, then take checkpoints and run from
>>> checkpoints.
>>>
>>> I will report whether this works or not.
>>>
>>> Thanks.
>>>
>>> --
>>> Best Regards
>>> Yan Zi
>>>
>>> On 27 Aug 2014, at 15:44, Mitch Hayenga wrote:
>>>
 There are probably three main patches that could help.  The fact you
 mention the timer interrupt makes me think Andreas is right and these
>>> might
 solve your issue.

 1. http://reviews.gem5.org/r/2363/  - o3 is supposed to stop fetching
 instructions immediately once a quiesce instruction is encountered,
some
 managed to sneak by.  Quiesce is used for things like sleeping until
an
 interrupt occurs, etc.  Without this patch, we experienced the case
where
 o3 state would get corrupted and an instruction would sit at commit
until
 the next timer interrupt happened.  At which point taking the
interrupt
 would clear the state and execution would continue (until this same
bug
 happened again).

 2. http://reviews.gem5.org/r/2367/  - If o3 was being drained while an
 interrupt occurred on x86, it could deadlock.

 3. I believe this last patch will be posted in a day or two.  x86
>>> currently
 does not tag any instruction that suspends() the CPU as a "quiesce".
>>> This
 is required by o3 to properly operate, but not by the Atomic CPU.
This
 makes the issue in #1 far more likely to occur.  It's pretty amazing
that
 x86 booted linux at all on o3 without this.  I believe this patch
will be
 posted shortly, but otherwise you could just tag the "MicroHalt"
 instruction as "IsQuiesce" yourself.

 So a combination of those things (mainly the last one) could lead to
what
 you are seeing.


 On Wed, Aug 27, 2014 at 12:59 PM, Zi Yan via gem5-users <
>>> gem5-users@gem5.org
> wrote:

> OK. Could you please tell me which patches are there? In the
> review board there are quite a lot of new patches waiting
> for review.
>
> I can apply those patches myself and do a quick test.
>
> Thanks.
>
> --
> Best Regards
> Yan Zi
>
> On 27 Aug 2014, at 13:56, Andreas Hansson wrote:
>
>> Hi Yan,
>>
>> I would suspect this is due to a bug in the X86 O3 CPU. There have
>>been
>> quite a few fixes posted on the review board for similar issues. I
>>hope
> to
>> have these committed in the next week or so.
>>
>> Andreas
>>
>>
>> On 27/08/2014 18:02, "Zi Yan via gem5-users" 
> wrote:
>>
>>> Hi all,
>>>
>>> I am running kmeans via hadoop in gem5 X86 FS mode. I am using
>>> linux kernel 3.2.60 with configuration file linux-2.6.28.4 from
>>> gem5.org.
>>>
>>> I take a checkpoint before a map task and put a "m5 exit" after the
>>> map
>>> task.
>>> I am using *X86kvmCPU* to take checkpoints.
>>>
>>> When I restore from the same checkpoint, atomic CPU and O3 CPU
>>>give me
>>> quite different executed instructions:
>>> 1) atomic CPU executes about 350 million instructions, reaches "m5
> exit",
>>> then stops simulation.
>>> 2) O3 CPU executes more than 12 billion instructions, and still not
>>> reac