[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4790A6C0.7070002@gmail.com>
Date: Fri, 18 Jan 2008 08:16:48 -0500
From: Gregory Haskins <gregory.haskins.ml@...il.com>
To: linux@...dmangroup.com
CC: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
rostedt@...dmis.org
Subject: Re: SCHED_FIFO & system()
linux@...dmangroup.com wrote:
> Hello,
> I have some strange behavior in one of my systems.
>
> I have a real-time kernel thread under SCHED_FIFO which is running every
> 10ms.
> It is blocking on a semaphore and released by a timer interrupt every 10ms.
> Generally this works really well.
>
> However, there is a module in the system that makes a / system() / call
> from c-code in user-space;
>
> system("run_my_script");
>
> By calling and running a bash script. Independent of how the actual
> script looks like the real time kernel thread does not get scheduled under
> the time of 80ms -- the time it takes for the system() call to finish.
>
> I can see when running a LTT session that the wake_up event occurs for
> the real time thread 10ms into the system call but nevertheless the real
> time kernel thread does not get scheduled.
>
> The thread that calls system("run_my_script") is configured as SCHED_OTHER.
>
> The Kernel is 2.6.21.
>
>
> Anybody who recognize this or similar situations?
Hi,
I am not sure if this is whats happening to you (*), but there is a
known problem in the mainline tree related to the system allowing lower
priority threads to stay on the CPU under certain circumstances.
You can see the problem happening with the following test:
http://rt.wiki.kernel.org/index.php/Preemption_Test
and I know the problem goes back to at least 2.6.16.
Steven Rostedt and I submitted some patches to address the issue, and
they have been accepted into Ingo's sched-devel tree. I would suggest
trying your code against Ingo's tree and see if the problem persists.
You can get it from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git
In the event that this does fix your issue, I will defer to Ingo for
if/when he plans to push these upstream.
(*) I have no information on whether the futex-plist implemetation was
pulled from the tree to cause your regression. It is possible that the
changes between 22 and 23 are just tickling your environment enough to
bring out this RT-preempt issue.
HTH!
Regards,
-Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists