[PTLsim-devel] PTLSim on AMD-64

Wed Apr 16 06:23:48 EDT 2008

Hehe...
Nice to hear from you again :)
I believe that PTLSim is, soon, going to once again become No.1 priority
here, in our department. :) But until then, some papers need to be written.
And I had to temporarily switch to M5 simulator, since I was already
familiar with its code base, and I knew that this simulator *is* stable. A
bad thing with it is that it's an Alpha simulator. And it's very slow. In
the future we're going to play with x86 apps and therefore we'll have to
move away from M5.

Now, I had most of my problems with switching back and forth,
simulation/native. We used this same property for adding our functionality
to the simulator, as Matt suggested us.
In order for stability problem to be addressed... probably interaction with
Xen would need to checked out.
Matt once also said that there's a plan to replace functionality of PTLSim
with Linux-kernel-like functionality. I think it would be a good move. *
Maybe* not performance-wise, but in portability, capabilities and stability
definitely :) It could be combined with e.g. full-system QEMU simulator with
128 cores, and there you have it... PTLSim running on 128 cores :)
that would be a good thing to have...

Sasha

On Wed, Apr 16, 2008 at 11:36 AM, Stephan Diestelhorst <
stephan.diestelhorst at gmail.com> wrote:

> > The problem was instability, with multicore FullSystem simulations.
>
> There was one major problem with multi-threaded / multi-core simulation:
> The atomic RMW instructions (which are used to realise mutexes, locks and
> other similar constructs e.g. inside the linux kernel, libc and
> pthreads) were not
> actually atomic. I've sent a patch for that quite a while ago, which fixed
> most
> of my instabilities in the past.
>
> In addition to that, there are serious stability issues when switching
> back and
> forth between simulation and native execution. Matt has once suggested
> that
> this might be due to races between the hypervisor taking over and PTLsim
> releasing the once simulated core "into the wild".
>
> > Anyway, this problem will probably last while PTLSim is bounded to Xen.
> We
> > hope that will change soon.
>
> I'm again working on PTLsim now, and fixing this issue is on my list of
> things.
> At some point Matt had a developer position available for someone who
> would
> port PTLsim to use QEMU (or KVM?) instead of Xen as a platform. I don't
> know
> how much progress has been made so far, perhaps his offer is still valid.
>
> In addition: Please do not only hope. This stuff is open-source. I guess
> every
> help in fixing is appreciated.
>
> > BTW, the multicore simulation is not yet cycle accurate! And if you're
> doing
> > single core full-system simulations you're probably OK, with both
> stability
> > and accuracy.
>
> Neither is the single-core. I have a patch upcoming that adds true
> multiple cores
> and a _minimal_ coherency protocol. Stay tuned!
>
> Cheers,
>   Stephan
>

-- 
Saša Tomić
BSC - Barcelona Supercomputing Center
c\ Gran Capita 2-4, Nexus I/204, 08034 Barcelona, España
Tel.: , web: http://www.kalaj.org/stomic/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://ptlsim.org/pipermail/ptlsim-devel/attachments/20080416/b866fa02/attachment-0001.htm 