NPTL/SMP/NUMA

NPTL/SMP/NUMA

[William Voorsluys]

Hi,

I've been reading about the advantages of the NPTL threads library but I
couldn't find the answers for some questions. The main doubt is related to
its advantages on SMP machines.
Many things have been made on the kernel to make the threads library
better, like the introduction of futexes, changes on the signal handling
mechanism, use of new architecture specific data structures, and so on. A
lot is said about the benefits of using the new threads implementations on
SMP machines. I'd like to know which changes have been made specifically
thinking on SMP machines, and which have been made to other purposes?
Is there any feature on the library/kernel that make it possible to
exploit the benefits of NUMA systems?

Thanks

William 

Re: NPTL/SMP/NUMA

[Alan Cox]

On Maw, 2003-06-03 at 23:26, William Voorsluys wrote:
> thinking on SMP machines, and which have been made to other purposes?
> Is there any feature on the library/kernel that make it possible to
> exploit the benefits of NUMA systems?

NUMA systems don't have any benefits (well other than engineering 
considerations like practicality of construction). From a software
perspective NUMA is simply a question of making the loss as little
as possible.

There are patches to do more NUMA aware scheduling which help a bit
as well as to do things like replicate the kernel code to each node.

Re: NPTL/SMP/NUMA

[Martin J. Bligh]

>> thinking on SMP machines, and which have been made to other purposes?
>> Is there any feature on the library/kernel that make it possible to
>> exploit the benefits of NUMA systems?
> 
> NUMA systems don't have any benefits (well other than engineering 
> considerations like practicality of construction). 

Personally, I'd say that's pretty important ;-) But I get your point ...

On the other hand, you could look at it as "better local latency" rather
than "worse remote latency". Particularly if you stand on a big Sun
server when you look, where everything sucks equally for memory access 
latencies ;-)

> From a software perspective NUMA is simply a question of making the 
> loss as little as possible.

 
> There are patches to do more NUMA aware scheduling which help a bit
> as well as to do things like replicate the kernel code to each node.

The NUMA scheduling code isn't very bright about threads right now,
but we will fix that soon enough ;-)

M.