Hi, all,
I am trying to simulate a system with 4 cores, a test command line is as follow:
build/X86/gem5.opt configs/example/se.py -n 4 --cpu-type=DerivO3CPU
--mem-type=DDR4_2400_8x8 --mem-size=8GB --caches --l1d_size=64kB
--l1i_size=32kB --l2cache --l2_size=512kB -c
Hi Shehab,
As Jason pointed out, I won’t be surprised if you are having issues with
classic caches running workloads that rely on locking mechanisms. Your
pthread implementation is possibly using some synchronization variables
which requires cache coherence to maintain its correctness, and
Hi Shehab,
IIRC, there are some issues when using classic caches + x86 + multiple
cores on full system mode. I suggest using Ruby (MESI_two_level or
MOESI_hammer) for FS simulations.
Jason
On Fri, Sep 6, 2019 at 11:24 AM Shehab Elsayed wrote:
> My latest experiments are with the classical
My latest experiments are with the classical memory system, but I remember
trying Ruby and it was not different. I am using kernel 4.8.13 and
ubuntu-16.04.1-server-amd64 disk image. I am using Pthreads for my Hello
World program.
On Fri, Sep 6, 2019 at 1:13 PM Pouya Fotouhi wrote:
> Hi Shehab,
Hello all!
It's been a while since there's been a gem5 announcement. I apologize if
you get multiple copies of this email, but I'm trying to cast a wide net
with this announcement.
I'd like announce a new project: RE-gem5. RE-gem5 is a directed effort to
rejuvenate the underlying infrastructure
First of all, thanks for your replies, Ryan and Jason.
I have already pulled the latest changes by Pouya and the problem still
persists.
As for checkpointing, I was originally doing exactly what Jason mentioned
and ran into the same problem. I then switched to not checkpointing just to
avoid any
Hi Shehab,
One quick note: There is *no way* to have deterministic behavior when
running with KVM. Since you are using the hardware, the underlying host OS
will influence the execution path of the workload.
To try to narrow down the bug you're seeing, you can try to take a
checkpoint after
Yes, running in full system.
I cant even run arm fs on my home computer (arch linux) or on campus
(centos7). Under vm with ubuntu lts, it runs fine.
For x86 fs, parsec benchmarks work better out of the box when run under a
vm.
Ryan Gambord
On Fri, Sep 6, 2019, 08:21 Shehab Elsayed wrote:
>
That's interesting. Are you using Full System as well? I don't think FS
behavior is supposed to be so dependent on the host environment!
On Fri, Sep 6, 2019 at 11:16 AM Gambord, Ryan
wrote:
> I have found that gem5 behavior is sensitive to the execution environment.
> I now run gem5 inside an
I have found that gem5 behavior is sensitive to the execution environment.
I now run gem5 inside an ubuntu vm on qemu and have had much more
consistent results. I haven't tried running kvm gem5 inside a kvm qemu vm,
so not sure how that works, but might be worth trying.
Ryan
On Fri, Sep 6,
I was wondering if anyone is running into the same problem or if anyone has
any suggestions on how to proceed with debugging this problem.
On Mon, Jul 29, 2019 at 4:57 PM Shehab Elsayed wrote:
> Sorry for the spam. I just forgot to mention that the system configuration
> I am using is mainly
On Fri, Sep 6, 2019 at 3:23 AM Tom Ray wrote:
>
> Hi Santilli,
>
> I have checked the master (https://gitlab.com/arm-hpc/gem5/commits/master) and
> the ARM SVE related commits have not been merged into master. I wonder
> whether the master is that master you have mentioned.
>
>
Master is at:
12 matches
Mail list logo
