Re: [Gems-users] Problems binding threads to cabinets

[Jayaram Bobba <bobba@xxxxxxxxxxx>]

Rubén Titos wrote:
> Dear list,
>
> I'm having some trouble with the way gems 2.0 binds threads to 
> processors: when I run a transactional benchmark (i.e. btree) I always 
> get the error "pset_bind: invalid argument" when threads call the 
> function tm_bind_to_cabinet. (I'm using a sarek machine sol10-usiii+ 
> and  simics 2.2.19).
tm_bind_to_cabinet takes the processor set number as an argument. It 
fails if you pass
an invalid processor set number. You can still run the benchmark. 
However, you would have
some unbound threads that could lead to long-latency context switches 
and poor performance with
the spin barriers.
> I've tried to create as many processor sets as threads before running 
> the benchmark, using the command "psrset -c", and then assign each 
> processor to a different processor set. The problem is that I can't 
> assign processor 0 since it's busy:
> bash-3.00# psrinfo
> 0       on-line   since 06/02/2002 07:00:35
> 1       on-line   since 06/02/2002 07:00:40
> bash-3.00# psrset -c
> created processor set 1
> bash-3.00# psrset -c
> created processor set 2
> bash-3.00# psrset -a 1 1
> processor 1: was not assigned, now 1
> bash-3.00# psrset -a 2 0
> psrset: cannot assign processor 0: Device busy
> bash-3.00
>
> Doing this, I run the benchmark (with 2procs) and I get one error in 
> pset_bind (tm_bind_to_cabinet). My guess is it fails for the processor 
> that wasn't assigned (since I get two times the error if I dont 
> create/assign psets at all).
> Can anybody elaborate on how to bind threads with psrset/pset_bind in 
> gems 2.0?
You are right. pset_bind fails when it tries to bind the second thread 
to processor set 2.
Solaris allows you to bind upto n-1 processors to various processor 
sets, where n is the
total number of processors in the system. So in your case, you can only 
create one processor set.
> Another doubt related to this: I'm using the scripts generated by 
> gen-scripts, and I'm confused about this line (found at the beginning 
> of btree.simics and other microbenchmarks).
>     proc_no = [0, 1, 4, 5, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
> It seems as if proc numbers where different from what one could expect 
> (0..num_p-1) and it was necessary to remap the numbers. However, 
> calling psrset with proc_no[j] instead of just j doesn't work either. 
> Can anyone clarify this as well?
proc_no array is used to assign processors to processor sets. It is 
specific to the checkpoint that we use and reflects
the processor id space in our checkpoints. You should specify your own 
array based on the output from psrinfo.
Jayaram