context 0 should be the OS when it is executing on GEMS. Whenever it issues a memory request, it's threadID will be 0. I know this is how it works under linux, and I assume it's the same under Solaris.
Phil
On May 30, 2011, at 10:25 AM, Hamid Reza Khaleghzadeh wrote:
> Hi,
>
> I have question about pset_bind() in Solaris. If possible please answer me.
> I have written a pthread application that contains two threads. Two psets was defined in this application and each thread of the application is bound to one of the defined psets. I have added a profiling facility to gems that logs address of all accessed memory requests along with ThreadID that issues that request.
> After reviewing the log file, I found that another thread (It's threadID is 0) was mapped to the defined psets. For example, Cpu2 and Cpu3 was defined as a pset and one thread of my pthread application was bound to this pset. After reviewing the application log file, I understood that thread 0 is mapped to the pset, too. We know that every thread must be mapped to a pset by pset_bind() and I have not mapped thread 0 to the pset. Could you tell me why this happened?
>
> Thanks.
|