On Thu, 15 Jun 2006, Mike Kravetz wrote:
On Mon, Jun 12, 2006 at 08:38:24AM -0700, Darren Hart wrote:
I started running this version of the patch with prio-preemt in a loop
over 10 hours ago, and it's still running. This seems to be the right fix.
Unfortunately, this test did eventually fail over in our environment.
John Stultz added the concept of 'interrupter threads' to the testcase.
These high priority RT interrupter threads, occasionally wake up and
run for a short period of time. Since these new threads are higher
priority than any other, they theoretically should not impact the
testcase. This is because the primary purpose of the testcase is to
ensure that lower priority tasks do not run while higher priority tasks
are waiting for a CPU.
After adding these interrupter threads, the tetscase fails (on a system
here) about 50% of the time. An updated version of prio-preempt.c is
attached. It needs the same headers/makefile/etc as originally provided
by Darren.
Any help figuring out what is happening here would be appreciated.
Well, I can't say understand what your test is supposed to test. But I
know having printf() inside something which is supposed to be RT is a big
no-no as it can block.
What if the first printf() after pthread_cond_wait() is blocking?
The interrupt threads probably use a lot of CPU overall and they have
priority 90. They might slow the output device for printf() so much down
that some queue becomes full and printf() must block.
Esben
--
Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
