public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Arun Srinivas <getarunsri@hotmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: scheduler/SCHED_FIFO behaviour
Date: Wed, 06 Apr 2005 22:27:44 -0400	[thread overview]
Message-ID: <1112840864.22577.38.camel@localhost.localdomain> (raw)
In-Reply-To: <BAY10-F593A133679EB2005D70E1FD93E0@phx.gbl>

On Thu, 2005-04-07 at 07:11 +0530, Arun Srinivas wrote:
> I am not sure if my question was clear enough or I couldnt interpret you 
> answer correctly.(If it was the case I apologise for that).
> 
> My question is, as I said I am measuring the schedule time difference 
> between my 2 of my SCHED_FIFO process in schedule() .But, I get only one set 
> of readings (i.e., schedule() is being called once which implies my process 
> is being scheduled only once and run till completion)
> 
> Also, as I said my interrupts are being processed during this time.I 
> inspected /proc/interrupts for this.So, my question was if interrupts heve 
> been processed several times the 2 SCHED_FIFO process which has been 
> interrupted must have been resecheduled several times and for this upon 
> returning from the interrupt handler the schedule() function must have been 
> called  several times to schedule the 2 process which were running.But, as I 
> said I get only one reading??
> 
> >From your reply, I come to understand that when an interrupt interrupts my 
> user process.....it runs straight way ....but upon return from the interrupt 
> handler does it not call schedule() to again resume my interrupted process? 

Exactly! Even going back to a user process, if that process is the
highest priority process than it does not need to call schedule.
Actually the only time it would call schedule, is if the interrupt
called wake_up_process, or did something that needed the need_resched
for the running task set.  Even if wake_up_process was called, if the
process was not higher in priority than the running process, then it
would not preempt it.

So...

1) Task running in user land.
2) interrupt goes off, switch to kernel mode.
3) execute interrupt service routine.
4) ISR calls wake_up_process (most likely on ksoftirqd)
5) ksoftirqd not as high a priority as running process (don't set
need_resched)
6) return from interrupt. need_resched not set. 
7) go back to user process running in user land.

There, is that clear. schedule is never called. Set ksoftirqd higher in
priority than your tasks, and you might start seeing scheduling. But
sometimes the functions needed to execute are done on return from
interrupt and not though ksoftirqd, so you still might not see a
schedule. But I'm sure you will.

-- Steve



  reply	other threads:[~2005-04-07  2:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-07  1:41 scheduler/SCHED_FIFO behaviour Arun Srinivas
2005-04-07  2:27 ` Steven Rostedt [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2005-04-03 23:08 sched /HT processor Steven Rostedt
2005-04-04 23:06 ` scheduler/SCHED_FIFO behaviour Arun Srinivas
2005-04-04 23:17   ` Steven Rostedt
2005-04-05  2:16     ` Arun Srinivas
2005-04-05  3: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=1112840864.22577.38.camel@localhost.localdomain \
    --to=rostedt@goodmis.org \
    --cc=getarunsri@hotmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox