Re: 2.6 vs 2.4 regression when running gnomemeeting

[Christian Meder <chris@onestepahead.de>]

On Sun, 2003-12-21 at 09:57, Ingo Molnar wrote:
> * Christian Meder <chris@onestepahead.de> wrote:
> 
> > I tried to verify your suggestion and found that the P_RTEMS symbol is
> > not defined on Linux. It seems to be some other kind of realtime
> > operating system. So the code in question already uses usleep. Now I'm
> > still digging for other occurances of sched_yield in the pwlib
> > sources.
> 
> could you try to strace -f gnomemeeting? Maybe there's no sched_yield()
> at all. Could you also try to run the non-yielding loop code via:
> 
> 	nice -19 ./loop &
> 
> do a couple of such loops still degrade gnomemeeting?

I found the culprit. It's sched_yield again. When I straced gnomemeeting
even without load I saw a lot of sched_yields. So I googled around for
2.6 and sched_yield and found among others
http://www.hpl.hp.com/research/linux/kernel/o1-openmp.php by David
Mosberger. I tried gnomemeeting with the romp hack at the end of the
article which changes all sched_yields to noops via library preloading.
The difference was _really_ impressive. No matter how many non-yield
loops and kernel compiles I ran gnomemeeting didn't even skip once.

So the questionable code in pwlib is probably: 

> BOOL PSemaphore::Wait(const PTimeInterval & waitTime)
> {
>   if (waitTime == PMaxTimeInterval) {
>     Wait();
>     return TRUE;
>   }
>                                                                                 
>   // create absolute finish time
>   PTime finishTime;
>   finishTime += waitTime;
>                                                                                 
> #ifdef P_HAS_SEMAPHORES
>                                                                                 
>   // loop until timeout, or semaphore becomes available
>   // don't use a PTimer, as this causes the housekeeping
>   // thread to get very busy
>   do {
>     if (sem_trywait(&semId) == 0)
>       return TRUE;
>                                                                                 
>     PThread::Yield(); // One time slice
>   } while (PTime() < finishTime);
>  
>   return FALSE;

Defining Yield to noop and building a new libpt solved the problem
permanently for me.

It seems that not all people have got problems with gnomemeeting and
2.6. Damien Sandras (the gnomemeeting maintainer) for example reported
that he hasn't got any problems with gnomemeeting on 2.6 while compiling
in parallel. So I guess it's depending on the frequency of sched_yields
one gets in gnomemeeting. Which is probably depending on the processor
speed, etc.

That just leaves the question what is the proper fix, to send it
upstream and to note the phenomenon down in a faq.

Thanks to all who helped me with debugging advice and if anybody needs
further information just ask.


				Christian

-- 
Christian Meder, email: chris@onestepahead.de
 
What's the railroad to me ?
I never go to see
Where it ends.
It fills a few hollows,
And makes banks for the swallows, 
It sets the sand a-blowing,
And the blackberries a-growing.
                      (Henry David Thoreau)