Re: 2.6 vs 2.4 regression when running gnomemeeting

[Christian Meder <chris@onestepahead.de>]

On Sat, 2003-12-20 at 18:42, Ingo Molnar wrote:
> * Christian Meder <chris@onestepahead.de> wrote:
> 
> > > yep, i've looked at the source too and it doesnt do anything that 
> > > changed in 2.6 from an interactivity POV.
> > 
> > Stefan Bruens pointed out on the gnomemeeting-devel list that pwlib
> > which gnomemeeting is using executes sched_yield and that perhaps
> > there is a problem akin to the openoffice busy-loop on sched_yield()
> > problem earlier this year. I found the following sched_yield code in
> > pwlib 1.5.2 in src/ptlib/unix/tlibthrd.cxx:
> 
> ah! I suspected something like this, that's why i looked at the source,
> but i didnt check dependent libs ...
> 
> >     if (++retry < 1000) {
> > #if defined(P_RTEMS)
> >       sched_yield();
> 
> > Is this obviously broken for 2.6 usage ?
> 
> 
> yes, very definitely broken. For one, it does not provide predictable
> timing - 1000 loops of sched_yield() can be very different on different
> CPUs. But the main problem is that on 2.6 sched_yield() is much more
> agressive. Something like this was fixed in OpenOffice earlier this
> year, and it improved interactivity quite visibly. Could you remove the
> sched_yield() and replace it with a 20 msec nanosleep (and keep the rety
> loop to 100)? Does that make any difference?

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.

I'll keep you posted with further facts.


			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)