This is the mail archive of the glibc-linux@ricardo.ecn.wfu.edu mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Slow pthread_create() under high load


On Sat, 25 Mar 2000 sasha@mysql.com wrote:

> Date: Sat, 25 Mar 2000 04:12:03 -0700
> From: sasha@mysql.com
> To: Kaz Kylheku <kaz@ashi.footprints.net>
> Cc: glibc-linux@ricardo.ecn.wfu.edu, linux-kernel@vger.rutgers.edu,
     mysql@lists.mysql.com, monty@mysql.com
> Subject: Re: Slow pthread_create() under high load
> 
> <cut>
> 
> > 
> > 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().
> 
> At what point in this process will pthread_create() return? It actually returns

It returns after all of the bookeeping for creating the thread is done: 
setting up the stack, thread context structure and calling clone(). As the
last step, the manager wakes up the pthread_create() requestor.

UTSL

> very fast - the slow part is getting to the first line of the function that is
> being passed to pthread_create() in the newly created thread. 

That suggests that the scheduler is slow in getting this thread up and running;
probably because you have swamped it with lots of other threads that are
chewing up significant portions of their time quanta.

> My guess is that clone() should return very fast to the original thread, but
> might take a while to return to the newly created thread, which is what is
> causing the problem.

Even if you make it a high priority thread, it does not start that way; it
becomes high priority after it executes the code which performs the adjustment.
So you can't expect a newly created high priority thread to immediately take
over as soon as it is presented to the scheduler.

If you want a thread to ``spin up'' fast in response to something, you should
have a live thread that is ready to go, and can be unblocked rapidly with a
simple pthread_cond_broadcast, sem_post or equivalent. Such a thread will
already have the desired priority, and its kernel resources already allocated.
So at worst it will suffer some page faults if its stack or other working
data has been swapped out.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]