Very long startup time for a new thread

Very long startup time for a new thread

[Mikael Starvik]

(This is on a 200 MIPS embedded architecture).

On a heavily loaded system (loadavg ~4) I create a new pthread. In this
situation it takes ~4 seconds (!) before the thread is first scheduled in
(yes, I have debug outputs in the scheduler to check that). In a 2.4 based
system I don't see the same thing. I don't have any RT or FIFO tasks. Any
ideas why it takes so long time and what I can do about it?

Appreciate any help
/Mikael

Re: Very long startup time for a new thread

[Arjan van de Ven]

On Thu, 2006-07-13 at 08:07 +0200, Mikael Starvik wrote:
> (This is on a 200 MIPS embedded architecture).
> 
> On a heavily loaded system (loadavg ~4) I create a new pthread. In this
> situation it takes ~4 seconds (!) before the thread is first scheduled in
> (yes, I have debug outputs in the scheduler to check that). In a 2.4 based
> system I don't see the same thing. I don't have any RT or FIFO tasks. Any
> ideas why it takes so long time and what I can do about it?

I assume you're using a new enough glibc that supports NPTL ?

Re: Very long startup time for a new thread

[Mike Galbraith]

On Thu, 2006-07-13 at 08:07 +0200, Mikael Starvik wrote:
> (This is on a 200 MIPS embedded architecture).
> 
> On a heavily loaded system (loadavg ~4) I create a new pthread. In this
> situation it takes ~4 seconds (!) before the thread is first scheduled in
> (yes, I have debug outputs in the scheduler to check that). In a 2.4 based
> system I don't see the same thing. I don't have any RT or FIFO tasks. Any
> ideas why it takes so long time and what I can do about it?

If your new thread is runnable but not selected for those ~4 seconds, it
could be the interactivity code.  Try disabling that.

If you want to try a patch that targets this area, I have an old one for
2.6.16 you can play with.  With it, you can pretty much disable the
interactivity code without losing dynamic priority adjustment.  I also
have one for 2.6.17, and that one removes the interactivity code
entirely (hmm) but it also actively intervenes in scheduling decisions,
so might not be a good diagnostic.

	-Mike

RE: Very long startup time for a new thread

[Mikael Starvik]

Nope, no NPTL. Actually this system uses the pthread implementation in
uC-libc.

-----Original Message-----
From: Arjan van de Ven [mailto:arjan@infradead.org] 
Sent: Thursday, July 13, 2006 9:15 AM
To: Mikael Starvik
Cc: 'Linux Kernel Mailing List'
Subject: Re: Very long startup time for a new thread


On Thu, 2006-07-13 at 08:07 +0200, Mikael Starvik wrote:
> (This is on a 200 MIPS embedded architecture).
> 
> On a heavily loaded system (loadavg ~4) I create a new pthread. In this
> situation it takes ~4 seconds (!) before the thread is first scheduled in
> (yes, I have debug outputs in the scheduler to check that). In a 2.4 based
> system I don't see the same thing. I don't have any RT or FIFO tasks. Any
> ideas why it takes so long time and what I can do about it?

I assume you're using a new enough glibc that supports NPTL ?

RE: Very long startup time for a new thread

[Mikael Starvik]

Thanks to all that have made suggestions. Finnaly we found that 

#define MIN_TIMESLICE 5
#define DEF_TIMESLICE 25

works much better for us. Maybe it is an effect of that we have HZ=100 ?

/Mikael

-----Original Message-----
From: Mikael Starvik [mailto:mikael.starvik@axis.com] 
Sent: Thursday, July 13, 2006 8:08 AM
To: 'Linux Kernel Mailing List'
Subject: Very long startup time for a new thread


(This is on a 200 MIPS embedded architecture).

On a heavily loaded system (loadavg ~4) I create a new pthread. In this
situation it takes ~4 seconds (!) before the thread is first scheduled
in (yes, I have debug outputs in the scheduler to check that). In a 2.4
based system I don't see the same thing. I don't have any RT or FIFO
tasks. Any ideas why it takes so long time and what I can do about it?

Appreciate any help
/Mikael