This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: Slow pthread_create() under high load
- To: glibc-linux at ricardo dot ecn dot wfu dot edu
- Subject: Re: Slow pthread_create() under high load
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Date: Fri, 24 Mar 2000 21:02:17 -0800 (PST)
- cc: linux-kernel at vger dot rutgers dot edu, mysql at lists dot mysql dot com, monty at mysql dot com
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
On Fri, 24 Mar 2000 sasha@mysql.com wrote:
> Date: Fri, 24 Mar 2000 16:26:16 -0700
> From: sasha@mysql.com
> Reply-To: glibc-linux@ricardo.ecn.wfu.edu
> To: linux-kernel@vger.rutgers.edu
> Cc: mysql@lists.mysql.com, glibc-linux@ricardo.ecn.wfu.edu, monty@mysql.com
> Subject: Slow pthread_create() under high load
>
> Hello, everyone. I've been benchmarking MySQL under high load on Linux ( kernel
> 2.2.12, glibc 2.1.2), and noticed a rather interesting occurence with unusually
> slow connection establishment process ( compared to how fast the actual query
> would execute, which I traced to a problem in pthread_create() in glibc:
The LinuxThreads pthread_create works by passing a message through a pipe to a
manager thread, and then blocking. The manager thread allocates the resources
for the new thread and then creates it via clone(). It then unblocks the
original thread which is suspended inside pthread_create().
It's not all that light of a procedure, as you can see. If you need a fast
response time in assigning a thread to a task to be done, consider thread pool
techniques for reusing existing threads, and for limiting the number of active
threads.