[PTLsim-devel] Problems because of setting affinity

Thu Oct 18 05:41:38 EDT 2007

Hi,

I also have the same problem, even with the unmodified version of PTLsim 
rev219.
I should stress that we are all using multicores (VCPUS>1) in PTLsim. If 
I use a single-core version, I don't see this problem (this doesn't mean 
that it doesn't exist). But, for our research, we need multicores.
With the rev221 the cores don't even start running if I use more that 1 
core.
If I use only one core, it works correctly.

Is there any help, and can somebody experienced with PTLsim and Xen try 
to help us and find the bug?
I can (and will) try to find it myself, but it's definitely going to be 
a slow and painful process.

And I really want to say here that I really really like the coding style 
of the PTLsim. This is one of the best written programs I've seen. I'm 
serious. :) Excellent work, really :)

thank you very much for everything,
Sasha

Stephan Diestelhorst wrote:
>>> Hi,
>>>
>>> I run PTLsim in fullsystem mode. I run mutli-threaded applications on
>>> the simulator and explicitly bind threads to the CPUs by setting the
>>> CPU affinity because applications that I simulate are small and the OS
>>> does not schedule the threads to different CPUs.
>>>
>>> The problem that I observe is that in certain point the simulation
>>> stops and the simulator does not simulate/execute any instructions (0
>>> instructions/second).
>>>
>>> Do you have any similar problems, and do you know why does it happen?
>>>
>>> We (me and my colleague) suppose that the simulator does not run the
>>> other VCPUs. And when thread 0 finishes execution it waits on join
>>> point. But because the other CPUs are not running, they don't execute
>>> the other threads (1, 2, 3) and the simulation blocks.
>>>
>>> When I don't set the CPU affinity everything is fine (unless the
>>> threads are not assigned to non-running VCPU). This happens with the
>>> SMT and the sequential cores.
>>>
>>> I use code revision 220 (it is a little bit old).
>>>       
>> Please ask Hui Zeng (hzeng at cs.binghamton.edu) about this. He designed the
>> SMT core, and he figured out a way to deal with the affinity problem you
>> describe.
>>     
>
> Count me in on this! So far, I presumed this was because of my real multi-core 
> hacks, but obviously, it is a real issue. For me, the cores would eventually 
> end up being blocked (the Xen VCPU stays in the blocked state and only 
> occasionally goes running, presumably when a timer interrupt arrives) and 
> somehow never jumps into the benchmark again (which has been pinned 
> explicitly too).
>
> However, initially, the test-code was running well on the simulator, even in 
> the other cores for some while, however it is hard for me to track down why 
> exactly it has stopped working. Any hints on how to debug this?
>
> Even if it isn't the exactly the same issue (my hacked core vs. SMT) I'd be 
> curious to hear about any workarounds / bugfixes etc.
>
> Thanks!
>
> Stephan
>   

-- 
Saša Tomić
BSC - Barcelona Supercomputing Center
c\ Jordi Girona 29, Nexus I, 08034 Barcelona, España
Tel.: ,  
http://www.bsc.es

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://ptlsim.org/pipermail/ptlsim-devel/attachments/20071018/06b30949/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
Url : https://ptlsim.org/pipermail/ptlsim-devel/attachments/20071018/06b30949/attachment.bin 