[fpc-pascal] CPU affinity of TThread descendants

David W Noon david.w.noon at ntlworld.com
Sat Jan 24 23:50:58 CET 2009


On Tue, 2009-01-20 at 21:20 +0000, David W Noon wrote:

[snip]
> I have noticed one thing that might shed a little light on the topic:
> whenever I use a pipe for the output and I allow the pipe to stall with
> a full buffer, after execution is resumed the program sometimes restarts
> on the other CPU, but again all threads run on the same CPU.

I have finally tracked down what is going on here, and the above was a
significant hint.

In years past, the SMP Linux kernel would dispatch threads to CPUs using
a more-or-less round-robin basis: whenever a thread was preempted or
yielded its timeslice, the kernel would try to use the next available
CPU to dispatch the next true-ready thread. This had the nice effect of
spreading the thermal stress across all CPUs fairly evenly. However, if
the next true-ready thread happened to be in the same process as the
preempted/yielding thread, the caches, TLBs, etc., would have to be
flushed from the "current" CPU and then reloaded on the "next" CPU.

With current (2.6) kernels, this approach has changed. The "current" CPU
is reused, so that when the next true-ready thread happens to be in the
same process, the caches, TLBs, etc., are already valid.

Now, the thread routines in my test program all pivot on the one mutex
semaphore and do very little work before blocking again, so only one of
them can execute at any point in time. This has the effect of reducing
the execution model to that of a uniprocessor system. I added some bogus
CPU-intensive workload that ran outside of the mutex, so that this could
be executed by more than one thread concurrently. The upshot was that I
could get both CPUs at 100% busy.

This also led me to the discovery of a similar concept tp CPU affinity,
called thread scope. There are 2 APIs, called pthread_attr_setscope()
and pthread_attr_getscope(), the first of which allows a thread to be
created with a scope of PTHREAD_SCOPE_PROCESS or PTHREAD_SCOPE_SYSTEM.
The behaviour I was seeing was akin to PTHREAD_SCOPE_PROCESS, which ties
all threads of that scope within a process to dispatch on the same CPU.
However, Linux does not implement this thread scope; it only implements
PTHREAD_SCOPE_SYSTEM, which allows a thread to be dispatched on any CPU
to which it has an affinity.

-- 
Regards,

Dave  [RLU #314465]
=======================================================================
david.w.noon at ntlworld.com (David W Noon)
=======================================================================



More information about the fpc-pascal mailing list