Subj : Re: How to bind a POSIX thread to a specific CPU?
To   : comp.unix.tru64,comp.programming.threads
From : Ioannis E. Venetis
Date : Tue Jun 21 2005 05:01 pm

Hello,

Thank you for answering and giving your opinions.

> "RAD" is the term used by Tru64 UNIX for a "resource locality" on a NUMA 
> (non-uniform memory) system -- Alpha "Wildfire" and "Marvel" hardware 
> platforms. On a uniprocessor or traditional SMP system there's only one 
> RAD. They're hardware-oriented, so there's no way to create or change 
> them from software; only to control the allocation of resources among them.

This clarifies the general idea behind a RAD and is a good starting 
point to understand things better.

> As for binding... the first question for Ioannis would be "why would you 
> want to do that"? The unusual name "use_only_cpu" was carefully chosen; 
> binding is rarely an advantage to the application, and far more likely 
> to be harmful. (When you bind to a CPU you're still competing with other 
> threads for access to that CPU, but you're unable to use another that's 
> completely idle.) There ARE cases where binding is useful or even 
> critical; but far more often binding is used by people who not only have 
> no real idea what they're doing (or why) but who also lack the resources 
> and knowledge to perform and understand the measurements that would 
> prove they'd made a mistake.

I am aware of the complications of binding kernel-threads to CPUs on a 
multiprocessor system and I have some experience on these issues 
(although certainly not the experience you have). However, (as you 
already mentioned) I believe that there are cases where binding a 
kernel-thread to a CPU has advantages. Moreover, the application will 
not bind kernel-threads to CPUs all the time, but only if the user 
requests it. Therefore, the user might deside if it is an advantage to 
him/her or not, depending on the execution time in each case.

I have successfully used binding on other platforms (mainly Intel SMP 
systems, with and without HyperThreading running Linux) and I believe 
that applications that exclusively use the system and are CPU bound have 
in general better performance in this case. The same application has 
been tested on such systems and had better performance with binding. 
Therefore, I would like to test it also on Tru64.

Of course a NUMA architecture is quite different from those Intel 
systems and this is one more reason why I would like to experiment with 
this. I am just doing some research and experimenting is not bad in this 
case.

> Anyone who really needs binding on Tru64 UNIX (especially in a NUMA 
> environment) ought to be running V4.1B anyway, not V5.1; for a lot of 
> reasons.

Unfortunately, I am only using the system and can't upgrade the OS.

> If you really can't or won't upgrade, you'll need to figure out the 
> unsupported and largely undocumented depths of the Mach core functions 
> in Tru64 UNIX. It is possible, but it's not trivial.

These are bad news (at least for me :-) ). Anyway, it seems that I will 
have to live without this feature in my application under Tru64 UNIX or 
wait for an OS upgrade.

Best regards,

Ioannis

.