|
From: Tom H. <th...@cy...> - 2005-08-04 02:25:24
|
Nightly build on ginetta ( i686, Red Hat 8.0 ) started at 2005-08-04 03:10:07 BST Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 180 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 180 tests, 2 stderr failures, 1 stdout failure ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) none/tests/x86/yield (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Aug 4 03:18:55 2005 --- new.short Thu Aug 4 03:25:19 2005 *************** *** 8,13 **** ! == 180 tests, 2 stderr failures, 1 stdout failure ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) - none/tests/x86/yield (stdout) --- 8,12 ---- ! == 180 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Julian S. <js...@ac...> - 2005-08-04 08:16:46
|
none/tests/yield isn't stable in the sense that the outcome can be scheduling dependent. This also happened on Tom's RH73 machine a few nights back. I wonder what we should do about it. J On Thursday 04 August 2005 03:25, Tom Hughes wrote: > Nightly build on ginetta ( i686, Red Hat 8.0 ) started at 2005-08-04 > 03:10:07 BST > > Checking out valgrind source tree ... done > Configuring valgrind ... done > Building valgrind ... done > Running regression tests ... failed > > Regression test results follow > > == 180 tests, 2 stderr failures, 0 stdout failures ================= > none/tests/faultstatus (stderr) > none/tests/x86/int (stderr) > > ================================================= > == Results from 24 hours ago == > ================================================= > > Checking out valgrind source tree ... done > Configuring valgrind ... done > Building valgrind ... done > Running regression tests ... failed > > Regression test results follow > > == 180 tests, 2 stderr failures, 1 stdout failure ================= > none/tests/faultstatus (stderr) > none/tests/x86/int (stderr) > none/tests/x86/yield (stdout) > > > ================================================= > == Difference between 24 hours ago and now == > ================================================= > > *** old.short Thu Aug 4 03:18:55 2005 > --- new.short Thu Aug 4 03:25:19 2005 > *************** > *** 8,13 **** > > ! == 180 tests, 2 stderr failures, 1 stdout failure ================= > none/tests/faultstatus (stderr) > none/tests/x86/int (stderr) > - none/tests/x86/yield (stdout) > > --- 8,12 ---- > > ! == 180 tests, 2 stderr failures, 0 stdout failures ================= > none/tests/faultstatus (stderr) > none/tests/x86/int (stderr) > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Nicholas N. <nj...@cs...> - 2005-08-04 15:06:53
|
On Thu, 4 Aug 2005, Julian Seward wrote: > none/tests/yield isn't stable in the sense that the outcome > can be scheduling dependent. This also happened on Tom's > RH73 machine a few nights back. I wonder what we should do > about it. Rewrite it so it is deterministic? :) I would if I understood how that test works... anyone want to volunteer? N |
|
From: Julian S. <js...@ac...> - 2005-08-07 09:15:41
|
> > none/tests/yield isn't stable in the sense that the outcome > > can be scheduling dependent. This also happened on Tom's > > RH73 machine a few nights back. I wonder what we should do > > about it. > > Rewrite it so it is deterministic? :) I would if I understood how that > test works... anyone want to volunteer? The idea is to check that a thread doing P4 "rep nop" instructions makes progress more slowly than one that doesn't. rep nop is a hint for hyperthreaded P4s which tells the CPU to give priority to other threads running on the same CPU at the same time. As far as I know the hint is not observed or acted on at the OS level. For Valgrind, when such a hint is executed, control returns to the despatcher and hence to the scheduler, which does sys_yield for that thread*, hence using the kernel to mimic the effect. Problem is that this makes it impossible to reliabily differentiate successful simulation of this facility from arbitrary kernel-induced scheduling wierdness. J * In fact there is more to it (see scheduler.c line 720 ish). Swapping to another kernel thread was observed to create massive delays for threads in spin-wait loops. Not surprisingly -- a rep nop on real hardware might cause it to fall a few cycles behind, whereas a kernel thread swap must cost in the thousands of cycles. So I kludged the scheduler to instead keep running the same thread, but set its remaining bb-quantum to 100 at most. The effect is that a thread now has to execute 100 rep nops in short succession before a thread swap actually occurs. |