Re: scheduler/SCHED_FIFO behaviour

Re: scheduler/SCHED_FIFO behaviour

[Arun Srinivas]

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? 
Please help.

Thanks
arun



>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 23:33:05 -0400
>
>On Tue, 2005-04-05 at 07:46 +0530, Arun Srinivas wrote:
>
> >
> > So, what I want from the above code is whenever process1 or process2 is
> > being scheduled measure the time and print the timedifference. But, when 
>I
> > run my 2 processes as SCHED_FIFO processes i get only one set of
> > readings....indicating they have been scheduled only once and run till
> > completion.
> >
> > But, as we saw above if interrupts have been processed they must have 
>been
> > scheduled several times(i.e., schedule() called several times). Is my
> > measurement procedure not correct?
>
>No! Interrupts are not scheduled. When an interrupt goes off, the
>interrupt service routine (ISR) is executed. It doesn't need to be
>scheduled. It runs right where it interrupted the CPU. That's why you
>need to be careful about protecting data that ISRs manipulate with
>spin_lock_irqsave. This not only protects against multiple CPUs, but
>turns off interrupts so that an interrupt wont be called and one of the
>ISRs modify the data you need to be atomic.
>
>Your tasks are running and will be interrupted by an ISR, on return from
>the routine, a check is made to see if your tasks should be preempted.
>But since they are the highest running tasks and in FIFO mode, the check
>determines that schedule should not be called.  So you will not see any
>schedules while your tasks are running.
>
>Now, if you where running Ingo's RT patch with PREEMPT_HARDIRQ enabled,
>and your tasks were of lower priority than the ISR thread handlers, then
>you would see the scheduling. Maybe that is what you want?
>
>-- Steve
>
>

_________________________________________________________________
Send money to India 
http://ads.mediaturf.net/event.ng/Type=click&FlightID=17307&AdID=44925&TargetID=9763&Targets=9763&Values=414,868,1093,2385&Redirect=http:%2F%2Fwww.icicibanknripromotions.com%2Fm2i_feb%2Fnri_M2I_feb.jsp%3Fadid%3D44925%26siteid%3D1093%26flightid%3D17307 
Get a FREE 30 minute India Calling Card.

Re: scheduler/SCHED_FIFO behaviour

[Steven Rostedt]

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

Re: scheduler/SCHED_FIFO behaviour

[Arun Srinivas]

hi

  I spkoe to you some days ago regarding scheduling two processes together 
on a HT.As I told you before I run them as SCHED_FIFO processes.I understood 
the theory you told me in your previous reply as to why both of SCHED_FIFO 
processes get scheduled only once and then run till completion.

But, sometimes a see a occasional reschedulei.e., the 2 processes get 
scheduled one more time after they are scheduled for the 1st time. I ran my 
code 100 times and observed this behavior 8 out of  100 times. What could be 
the reason?
(As I said i want my 2 processes to run together without any reschedule 
after they are scheduled for the first time).

Thanks
Arun
>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
>
>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
>
>

_________________________________________________________________
Trailblazer Narain Karthikeyan http://server1.msn.co.in/sp05/tataracing/ 
Will he be rookie of the year?

Re: scheduler/SCHED_FIFO behaviour

[Steven Rostedt]

On Sun, 2005-05-01 at 07:36 +0530, Arun Srinivas wrote:
> hi
> 
>   I spkoe to you some days ago regarding scheduling two processes together 
> on a HT.As I told you before I run them as SCHED_FIFO processes.I understood 
> the theory you told me in your previous reply as to why both of SCHED_FIFO 
> processes get scheduled only once and then run till completion.
> 
> But, sometimes a see a occasional reschedulei.e., the 2 processes get 
> scheduled one more time after they are scheduled for the 1st time. I ran my 
> code 100 times and observed this behavior 8 out of  100 times. What could be 
> the reason?
> (As I said i want my 2 processes to run together without any reschedule 
> after they are scheduled for the first time).

 The only way a real time priority process of SCHED_FIFO gets
rescheduled, is if the process voluntarily calls schedule (you call a
system call that calls schedule), or a higher priority process gets
scheduled.  I don't know what your program is doing, or what priorities
that they are running with to know if something like this has occurred.

Also, if the programs you are running haven't been locked into memory
(they exist partially on the hard drive still), then it will take time
to map the code into memory when that code is called, and a schedule
will occur then as well. 

-- Steve

Re: scheduler/SCHED_FIFO behaviour

[Arun Srinivas]

The 2 processes which I  am measuring  are parent and child processes.I want 
both of'em to be scheduled at the same time.My code simply does the 
following:

1) From main(i.e., parent) create a shared memory seg. using shmget() and 
shmat(). This is for communication between parent and child. I am trying to 
use this as a locking mechanism to make them tightly coupled so that one 
does not race before the other.
2) create child by fork() and call shmat() to attach this segment to child 
too
3) In parent and child call ioctl() to pass their PID's from user space to 
kernel space...so that I can measure when the particular PID's are scheduled 
in the scheduler

I suppose shmget() dosent use a system call.So still confused about the 
occasional resechedule behavior.



>From: Steven Rostedt <rostedt@goodmis.org>
>To: Arun Srinivas <getarunsri@hotmail.com>
>CC: linux-kernel@vger.kernel.org
>Subject: Re: scheduler/SCHED_FIFO behaviour
>Date: Sun, 01 May 2005 11:51:25 -0400
>
>On Sun, 2005-05-01 at 07:36 +0530, Arun Srinivas wrote:
> > hi
> >
> >   I spkoe to you some days ago regarding scheduling two processes 
>together
> > on a HT.As I told you before I run them as SCHED_FIFO processes.I 
>understood
> > the theory you told me in your previous reply as to why both of 
>SCHED_FIFO
> > processes get scheduled only once and then run till completion.
> >
> > But, sometimes a see a occasional reschedulei.e., the 2 processes get
> > scheduled one more time after they are scheduled for the 1st time. I ran 
>my
> > code 100 times and observed this behavior 8 out of  100 times. What 
>could be
> > the reason?
> > (As I said i want my 2 processes to run together without any reschedule
> > after they are scheduled for the first time).
>
>  The only way a real time priority process of SCHED_FIFO gets
>rescheduled, is if the process voluntarily calls schedule (you call a
>system call that calls schedule), or a higher priority process gets
>scheduled.  I don't know what your program is doing, or what priorities
>that they are running with to know if something like this has occurred.
>
>Also, if the programs you are running haven't been locked into memory
>(they exist partially on the hard drive still), then it will take time
>to map the code into memory when that code is called, and a schedule
>will occur then as well.
>
>-- Steve
>
>

_________________________________________________________________
Thinking of Marriage. 
http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?74 Think 
BharatMatrimony.com

Re: scheduler/SCHED_FIFO behaviour

[Florian Schmidt]

On Mon, 02 May 2005 10:57:29 +0530
"Arun Srinivas" <getarunsri@hotmail.com> wrote:

> 1) From main(i.e., parent) create a shared memory seg. using shmget() and 
> shmat(). This is for communication between parent and child. I am trying to 
> use this as a locking mechanism to make them tightly coupled so that one 
> does not race before the other.
> 2) create child by fork() and call shmat() to attach this segment to child 
> too
> 3) In parent and child call ioctl() to pass their PID's from user space to 
> kernel space...so that I can measure when the particular PID's are scheduled 
> in the scheduler
> 
> I suppose shmget() dosent use a system call.So still confused about the 
> occasional resechedule behavior.

You might try the user triggered tracing which is available with Ingo's
realtime preemption patches.

Enable the latency tracing in the kernel confgig and 

echo 1 > /proc/sys/kernel/user_triggered_tracing

then in your code you want to be checked do this before the section:

gettimeofday (1, 1)

and

gettimeofday (1, 0)

after the section you want to be checked.. Every reschedule of the task
will result in a signal SIGUSR2 sent to your program and a latency trace
in the syslog..

..i think

Flo


-- 
Palimm Palimm!
http://affenbande.org/~tapas/

Re: scheduler/SCHED_FIFO behaviour

[Steven Rostedt]

On Mon, 2005-05-02 at 10:57 +0530, Arun Srinivas wrote:
> The 2 processes which I  am measuring  are parent and child processes.I want 
> both of'em to be scheduled at the same time.My code simply does the 
> following:
> 
> 1) From main(i.e., parent) create a shared memory seg. using shmget() and 
> shmat(). This is for communication between parent and child. I am trying to 
> use this as a locking mechanism to make them tightly coupled so that one 
> does not race before the other.
> 2) create child by fork() and call shmat() to attach this segment to child 
> too
> 3) In parent and child call ioctl() to pass their PID's from user space to 
> kernel space...so that I can measure when the particular PID's are scheduled 
> in the scheduler
> 
> I suppose shmget() dosent use a system call.So still confused about the 
> occasional resechedule behavior.

Uhh, yes it does:

$ vi shmget.c

i
#include <sys/ipc.h>
#include <sys/shm.h>

int main()
{
        shmget(123,123,0);
        return 0;
}
:wq

$ gcc -o shmget shmget.c
$ strace ./shmget
[snip]
  shmget(123, 123, 0)                     = -1 ENOENT (No such file or directory)
[snip]
---

So it is a system call.  

Now, I still don't know when you are using your locking (which is also a
system call) to run your code.  A child is usually added to the same run
queue as the parent.  So this means that it will be scheduled on the
same CPU as the parent. But if the other CPU scheduler notices that the
scheduling of processes on the CPUs are unbalanced, then it will pull
tasks from one CPU to the other. But once the tasks are running as
SCHED_FIFO on different CPUs, then they shouldn't be preempted.

BUT!!!

looking at the system call code for shmget:

asmlinkage long sys_shmget (key_t key, size_t size, int shmflg)
{
	struct shmid_kernel *shp;
	int err, id = 0;

	down(&shm_ids.sem);  ==========>>>>> Here we can schedule
	if (key == IPC_PRIVATE) {
		err = newseg(key, shmflg, size);
	} else if ((id = ipc_findkey(&shm_ids, key)) == -1) {
		if (!(shmflg & IPC_CREAT))
			err = -ENOENT;
		else
			err = newseg(key, shmflg, size);
	} else if ((shmflg & IPC_CREAT) && (shmflg & IPC_EXCL)) {
		err = -EEXIST;
	} else {
		shp = shm_lock(id);
		if(shp==NULL)
			BUG();
		if (shp->shm_segsz < size)
			err = -EINVAL;
		else if (ipcperms(&shp->shm_perm, shmflg))
			err = -EACCES;
		else {
			int shmid = shm_buildid(id, shp->shm_perm.seq);
			err = security_shm_associate(shp, shmflg);
			if (!err)
				err = shmid;
		}
		shm_unlock(shp);
	}
	up(&shm_ids.sem);

	return err;
}


So, if both the parent and child are going for the same shared memory,
you can cause one to schedule.

-- Steve

Re: sched /HT processor

[Steven Rostedt]

On Mon, 2005-04-04 at 04:22 +0530, Arun Srinivas wrote:
> Thanks. yes, a reschedule may not take place after a ms, if the currently 
> running task cannot be preempted by another task.
> 
> (1) But, can a reschedule happen within a millisec (or once a process is 
> scheduled can schedule() be called before the next millisec.) ?
> 

Yes.  For example: a high priority task may be waiting for some IO to
come in. Right after the normal timer interrupt scheduled another task,
the IO may come in and wake the high priority process up. This process
will preempt the other task right away. (ie. less than 1 ms).

> 2) Also in case argument (1) is not true, and I want rescheduling to be done 
> (i.e., schedule() called) in less than 1 ms , can I directly change the HZ 
> value in <asm-i386/param.h> and recompile my kernel so that my timer 
> interrupt will occur frequently?
> 

Well, 1) is true, but you can also increase HZ over 1000 if you like,
but that will usually cause more overhead, since, although a schedule
may not take place every HZ, a timer interrupt will.

-- Steve

scheduler/SCHED_FIFO behaviour

[Arun Srinivas]

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.)
2)entire system appears frozen....no mouse/key presses detected until the 
processes exit.

>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).
How can I verify that?

Thanks
Arun

>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: sched /HT processor
>Date: Sun, 03 Apr 2005 19:08:06 -0400
>
>On Mon, 2005-04-04 at 04:22 +0530, Arun Srinivas wrote:
> > Thanks. yes, a reschedule may not take place after a ms, if the 
>currently
> > running task cannot be preempted by another task.
> >
> > (1) But, can a reschedule happen within a millisec (or once a process is
> > scheduled can schedule() be called before the next millisec.) ?
> >
>
>Yes.  For example: a high priority task may be waiting for some IO to
>come in. Right after the normal timer interrupt scheduled another task,
>the IO may come in and wake the high priority process up. This process
>will preempt the other task right away. (ie. less than 1 ms).
>
> > 2) Also in case argument (1) is not true, and I want rescheduling to be 
>done
> > (i.e., schedule() called) in less than 1 ms , can I directly change the 
>HZ
> > value in <asm-i386/param.h> and recompile my kernel so that my timer
> > interrupt will occur frequently?
> >
>
>Well, 1) is true, but you can also increase HZ over 1000 if you like,
>but that will usually cause more overhead, since, although a schedule
>may not take place every HZ, a timer interrupt will.
>
>-- Steve
>
>

_________________________________________________________________
Want to meet David Beckham? http://www.msn.co.in/gillette/ Fly to Madrid 
with Gillette!

Re: scheduler/SCHED_FIFO behaviour

[Steven Rostedt]

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

Re: scheduler/SCHED_FIFO behaviour

[Arun Srinivas]

ok.My program runs for 30 sec. approx. I did
#!/bin/sh
cat /proc/interrupts
run_test
cat /proc/interrupts

and I see there is quite some difference in the numbers.....meaning 
interrupts have been processed by the respective processor when my 
SCHED_FIFO processes have been running on both the cpu's.

But, then I am not sure why I am getting only 1 reading for the timediff. of 
schedule between my 2 processes.I do the following in my schedule() in 
sched.c:
( I make the kernel know the pid's of my 2 process...lets say pid1 and pid2)

/* in function schedule() in sched.c*/
schedule()
{
   need _resched:
                                /* after now=sched_clock(); I insert my code 
here*/
                              if(current->pid=pid1)
                                 {
                                    time1=now;
                                  }
                               elseif (current->pid=pid2)
                                 {
                                    time2=now;
                                 }
                                 /*after i get the 2 values for time1 and 
time2*/
                                 timediff= time1-time2;                // or 
time2 - time1 which ever is greater*/
                                 printk(KERN_ERR "%llu",timediff);
}

So, what I want from the above code is whenever process1 or process2 is 
being scheduled measure the time and print the timedifference. But, when I 
run my 2 processes as SCHED_FIFO processes i get only one set of 
readings....indicating they have been scheduled only once and run till 
completion.

But, as we saw above if interrupts have been processed they must have been 
scheduled several times(i.e., schedule() called several times). Is my 
measurement procedure not correct?

please help.
thanks
arun


>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
>
>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
>
>

_________________________________________________________________
The MSN Survey! 
http://www.cross-tab.com/surveys/run/test.asp?sid=2026&respid=1 Help us help 
you better!

Re: scheduler/SCHED_FIFO behaviour

[Steven Rostedt]

On Tue, 2005-04-05 at 07:46 +0530, Arun Srinivas wrote:

> 
> So, what I want from the above code is whenever process1 or process2 is 
> being scheduled measure the time and print the timedifference. But, when I 
> run my 2 processes as SCHED_FIFO processes i get only one set of 
> readings....indicating they have been scheduled only once and run till 
> completion.
> 
> But, as we saw above if interrupts have been processed they must have been 
> scheduled several times(i.e., schedule() called several times). Is my 
> measurement procedure not correct?

No! Interrupts are not scheduled. When an interrupt goes off, the
interrupt service routine (ISR) is executed. It doesn't need to be
scheduled. It runs right where it interrupted the CPU. That's why you
need to be careful about protecting data that ISRs manipulate with
spin_lock_irqsave. This not only protects against multiple CPUs, but
turns off interrupts so that an interrupt wont be called and one of the
ISRs modify the data you need to be atomic.

Your tasks are running and will be interrupted by an ISR, on return from
the routine, a check is made to see if your tasks should be preempted.
But since they are the highest running tasks and in FIFO mode, the check
determines that schedule should not be called.  So you will not see any
schedules while your tasks are running.

Now, if you where running Ingo's RT patch with PREEMPT_HARDIRQ enabled,
and your tasks were of lower priority than the ISR thread handlers, then
you would see the scheduling. Maybe that is what you want?

-- Steve