Real time scheduling and lock ups

Real time scheduling and lock ups

Post by Glen Rud » Fri, 09 Aug 1996 04:00:00



We are starting to experiment with the real time scheduling class with
solaris 5.4.  Scheduling Xsun as a real time process (the only one in
the system) sometimes produces system lockups that require a power flip.
The lockups always occur when the system as a whole is under a severe load.

Is anyone aware of any problems with Xsun or Solaris 5.4 that would cause
system lockups?    (Time quantums should equal the default)

Glen
--
:-);-):-};-}8-)8-}8-0:-]8-]B-)B-};-]8-]:-):-):-):-):-):-):-):-):-):-):-):-);-)
Glen L. Rudie                           Marquette Medical Systems

414.362.3309                            Milwaukee  WI, 53223  USA

 
 
 

Real time scheduling and lock ups

Post by Bryan O'Sulliva » Fri, 09 Aug 1996 04:00:00


r> We are starting to experiment with the real time scheduling class
r> with solaris 5.4.  Scheduling Xsun as a real time process (the only
r> one in the system) sometimes produces system lockups that require a
r> power flip.  The lockups always occur when the system as a whole is
r> under a severe load.

Bad programmer!  No biscuit!  You should NOT run the X server as a
real-time process because, as you are noticing, it will quite happily
slurp up all of your CPU at times.

r> Is anyone aware of any problems with Xsun or Solaris 5.4 that would
r> cause system lockups?

This is not a problem with either Solaris or Xsun, but rather with
you fiddling with the scheduling parameters.  You should only run
programs that have been carefully written to do real-time correctly in
real-time mode, and nothing else.  Other programs may or may not hog
all available CPU time, and thereby hang your machine.

        <b

--
Let us pray:
What a Great System.
Please Do Not Crash.


 
 
 

1. Mixed Time-Share & real-Time scheduling

 I seem to have this problem:

 Process Proc is started in real time, it in turns creates  THR_BOUND thrA.

 And then it drops itself in time share queue and creates THR_BOUND thrB.
(Actually there are a multitude of time-share and real-time threads.)

 Now thrA runs for a while (some milliseconds, say 15 ) and then it sleeps
for some milliseconds. (This is actually done by some interrupt mechanism
but that probably is not important either) and then thrB comes in prints some
data generated by thrA and goes to sleep. So far so good. Now however
if I go to another window and do an "ls" or another command, what I am
seeing is that if "ls" starts when the time-share thread thrB is running,
it can preempt thrB, and when the time to run thrA comes again, scheduler
doesn't necessarily run thrA. Soit appears that some piece of code
in the scheduler, when it gets a level 10 interrupt, it checks the
process table, and not the LWP table to find out if any real-time
LWPs are waiting or not. So if there is NO processes in real-time
queue, it assumes that there are no real-time LWPs waiting, and skips
that portion of the scheduler.... This is pure conjecture, but I am at
a loss to explain this behaviour. This can make me sometimes lose 10 or
20 milliseconds, invalidating houirs worth of run sometimes.
It works correctly if the process is in the real-time queue. Any
suggestions. (we got and tried patch -54 just to be sure...)

Sinan

PS: platform is SS10/512MP

2. Line Runner serial card?

3. Solaris2.0/2.1 Real time "Fast" timing/scheduling

4. Mounting Ext2fs-formatted partitions in 2.2.5-r

5. RT (Real Time) class Scheduling on svr4

6. Interpreting PPP logfile

7. Thread won't switch from real time scheduling policy to 'other'

8. Migrating from Windows to Linux

9. unix real time scheduling

10. Real-time Scheduling

11. questions about poll(2) in real-time scheduling

12. unix real-time scheduling?

13. real-time scheduling on unix?