Messages in this thread | | | Date | Sun, 21 Dec 2003 10:29:28 +1100 | From | Nick Piggin <> | Subject | Re: 2.6 vs 2.4 regression when running gnomemeeting |
| |
Christian Meder wrote:
>On Sat, 2003-12-20 at 12:19, Ingo Molnar wrote: > >>* Christian Meder <chris@onestepahead.de> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |