Re: [GnomeMeeting-devel-list] Re: 2.6 vs 2.4 regression when running gnomemeeting

[Damien Sandras <dsandras seconix com>]

Hi,

I have reported the problem upstream. I ignored that Yield () calls were
prohibited....


Le lun 22/12/2003 à 02:19, Christian Meder a écrit :
> 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
-- 
 _      Damien Sandras
(o-     
//\     It-Optics s.a.
v_/_    GnomeMeeting: http://www.gnomemeeting.org/
        FOSDEM 2004:  http://www.fosdem.org
        H.323 phone:  callto:ils.seconix.com/dsandras seconix com