Re: 2.6 vs 2.4 regression when running gnomemeeting

From: Nick Piggin
Date: Sat Dec 20 2003 - 18:31:04 EST




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/