[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: no.of threads using NPTL

Hash: SHA1

Saurabh Desai wrote:

>   I didn't see much difference between 2.5.41 and 2.5.42 with timings.
>   The test_str02 -n 8192 completed in 3 to 3.5secs using NPTL and in
>   0.7secs using NGPT.

I've run tests for nptl and ngpt 2.0.3 on a kernel with Ingo's patch
applied.  To account for the non-compliant ngpt implementation I have
two nptl tests, one with, one without stack guard.  Note that even the
version without stack guard is at a disadvantage since the stack guard
has to be disabled explicitly in the thread attribute, i.e., we make one
more function call.

I limit the number of threads to 32764 since this is what is possible to
achieve on my little machine.

The normal nptl version:

# time ./test_str02s -n 32764

    Creating 32764 threads

real    0m3.924s
user    0m0.416s
sys     0m3.305s

The nptl without stack guard:

# time ./test_str02as -n 32764

    Creating 32764 threads

real    0m3.333s
user    0m0.364s
sys     0m2.748s

The ngpt 2.0.3 code:

# time /home/drepper-local/ngpt-2.0.3/ttt/test_str02n -n 32764

    Creating 32764 threads

real    0m4.962s
user    0m0.002s
sys     0m0.003s

I cannot run the same test with LinuxThreads since the number of threads
is limited.   I stopped the program after it said is create 8190 threads
(the correct number), which took 19 secs.  So, ngpt is again faster than
LinuxThreads, but nptl is faster by 30% once the test were equalized.
This test, as the one we published before, is something an m-on-n
implementation should handle much better since the overhead related to
proces creation can be avoided.

>   I tried with 16K stacksize (ulimit -s 16), but NPTL seg faults after
>   32000+ threads creation.

I have seen segfaults as well if -l is used.  This really shouldn't
happen unless it is the kernel OOM handler which kills the application.
 I'll have to investigate this.

And yes, my system also has a limit of 32000+ threads with nptl while
ngpt goes much higher.  This is a limitation we accepted from the
beginning.  You can rectify it up to a limit by adding more RAM.  I
don't think it is unreasonable to "limit" a 512MB system to only 32000
threads.  Start working with the 50000+ threads you can create with ngpt
and you'll get your system to a standstill since due to swapping.

Side note: with the already mentioned signal stack patch for the kernel
the maximum number of threads will double.

Anyway, as a benchmark the test_str02.c file is usable.  It just wasn't
(and still isn't) a fair test due to the non-compliant ngpt
implementation.  If Ingo's patch gets accepted it has served us since it
helped to identify a general problem which is now hopefully fixed.


- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
Version: GnuPG v1.0.7 (GNU/Linux)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]