From: Steven Rostedt <rostedt@goodmis.org>
To: Arun Srinivas <getarunsri@hotmail.com>
Cc: juhl-lkml@dif.dk, LKML <linux-kernel@vger.kernel.org>
Subject: Re: scheduler/SCHED_FIFO behaviour
Date: Mon, 04 Apr 2005 19:17:04 -0400 [thread overview]
Message-ID: <1112656624.5147.34.camel@localhost.localdomain> (raw)
In-Reply-To: <BAY10-F37D1DA55DA1E869AA5A34DD93B0@phx.gbl>
On Tue, 2005-04-05 at 04:36 +0530, Arun Srinivas wrote:
> I am scheduling 2 SCHED_FIFO processes and set them affinity( process A runs
> on processor 1 and process B runs on processor 2), on a HT processor.(I did
> this cause I wanted to run them together).Now, in schedule() I measure the
> timedifference between when they are scheduled. I found that when I
> introduce these 2 processes as SCHED_FIFO they are
>
> 1)scheduled only once and run till completion ( they running time is around
> 2 mins.)
If they are the highest priority task, and running as FIFO this is the
proper behavior.
> 2)entire system appears frozen....no mouse/key presses detected until the
> processes exit.
>
If X is not at a higher priority than the test you are running, it will
never get a chance to run.
> >From what I observed does it mean that even the OS / interrupt handler does
> not occur during the entire period of time these real time processes run??
> (as I said the processes run in minutes).
The interrupts do get processed. Now the bottom halves and tasklets may
be starved if they are set at a lower priority than your test (ie. the
ksoftirqd thread). But most likely they are processed too.
> How can I verify that?
>
#!/bin/sh
cat /proc/interrupts
run_test
cat /proc/interrupts
If the run_test takes 2 minutes, you should see a large difference in
the two outputs.
-- Steve
> Thanks
> Arun
next prev parent reply other threads:[~2005-04-04 23:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bpH71yEXU00000397@hotmail.com>
2005-04-03 0:37 ` sched /HT processor Arun Srinivas
2005-04-03 1:17 ` Steven Rostedt
2005-04-03 2:16 ` Arun Srinivas
2005-04-03 4:22 ` Steven Rostedt
2005-04-03 7:52 ` Arun Srinivas
2005-04-03 11:17 ` Jesper Juhl
2005-04-03 15:31 ` Steven Rostedt
2005-04-03 22:52 ` Arun Srinivas
2005-04-03 23:08 ` Steven Rostedt
2005-04-04 23:06 ` scheduler/SCHED_FIFO behaviour Arun Srinivas
2005-04-04 23:17 ` Steven Rostedt [this message]
2005-04-05 2:16 ` Arun Srinivas
2005-04-05 3:33 ` Steven Rostedt
2005-04-03 22:52 ` sched /HT processor Arun Srinivas
2005-04-07 1:41 scheduler/SCHED_FIFO behaviour Arun Srinivas
2005-04-07 2:27 ` Steven Rostedt
2005-05-01 2:06 ` Arun Srinivas
2005-05-01 15:51 ` Steven Rostedt
2005-05-02 5:27 ` Arun Srinivas
2005-05-02 10:37 ` Florian Schmidt
2005-05-02 16:33 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1112656624.5147.34.camel@localhost.localdomain \
--to=rostedt@goodmis.org \
--cc=getarunsri@hotmail.com \
--cc=juhl-lkml@dif.dk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.