Re: 2.6 vs 2.4 regression when running gnomemeeting

[Nick Piggin]

Christian Meder wrote:

> On Sat, 2003-12-20 at 12:19, Ingo Molnar wrote:
>
> > * Christian Meder <chris@xxxxxxxxxxxxxxx> wrote:
> >
> >
> > > That would leave me with two possibilities: 2.6. is doing something
> > > different in the gnomemeeting case or gnomemeeting is doing something
> > > different in the 2.6 case. A cursory look at the gnomemeeting sources
> > > didn't give me the impression that it's doing anything which would be
> > > affected by 2.6 deployment but I'll ask on the gnomemeeting-devel list
> > > for advice.
> > 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:
>
>
>
> > static BOOL PAssertThreadOp(int retval,
> >                            unsigned & retry,
> >                            const char * funcname,
> >                            const char * file,
> >                            unsigned line)
> > {
> >  if (retval == 0) {
> >    PTRACE_IF(2, retry > 0, "PWLib\t" << funcname << " required " << retry << "
> > retries!");
> >    return FALSE;
> >  }
> >                                                                                
> >  if (errno == EINTR || errno == EAGAIN) {
> >    if (++retry < 1000) {
> > #if defined(P_RTEMS)
> >      sched_yield();
> > #else
> >      usleep(10000); // Basically just swap out thread to try and clear blockage
> > #endif
> >      return TRUE;   // Return value to try again
> >    }
> >    // Give up and assert
> >  }
> >                                                                                
> >  PAssertFunc(file, line, NULL, psprintf("Function %s failed", funcname));
> >  return FALSE;
> > }
>
> Is this obviously broken for 2.6 usage ?

Most probably, yes. That will cause the program to give up its entire
timeslice, so then all processes of any priority will be able to use
their entire timeslices before it.

If it gets called often, that would be the cause of your problem. Try
just using the usleep. You could even reduce the usleep timeout to
1000 or so, which 2.6 can take advantage of.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/