Original from  IVAN TODOROSKI  to ALL on 11-12-1998
Original Subject: Guess who's back... ;)

                         ---------------------------------------

IT>   So, let's get back on topic... I wasn't sure whether to put this
IT>   question here, but as it has to do with the internal design of OS/2
IT>   (hope Dennis Tonn is reading this and responds), I think this echo is
IT>   most adequate.
IT> 
IT>      It's about PRIORITIES

[...] 

 OK.. I'll take a crack at it.. I won't attempt to answer each of your
questions individually at this time. What I will do is describe the way it
works, and hopefully that will answer some of your questions. After that we
can get into specifics. 

 OK.. To start things off, there are 2 "flavors" of priority adjustment.
ABSOLUTE and DYNAMIC. Absolute means that whatever the programmer sets the
priority to, is what it gets and where it stays.
 There are 4 different priority levels with 32 "deltas" within each level.
The levels are IDLE, NORMAL, FIXED HIGH, and TIME CRITICAL. Fixed High is a
latter addition that came about when OS/2 server came out (OS/2 1.1 time
frame) and is sometimes called "server" priority. The numbers assigned to
these levels are not used internally by OS/2, all these values get "mapped"
to internal values. In fact there is another level in Warp 5 called "PEN",
but I don't know where it fits (yet). 
 Within each of these levels there are 32 deltas for fine tuning of
threads. 
 All these values are mapped into internal values that the scheduler and
dispatcher uses.The internal values range between 0100 and 081F. The delta
values are directly mapped into the lower 8 bits. Idle level is usually 
01xx and Time critical is usually 08xx. 
 The dispatcher will always locate the highest priority, ready to run 
thread and give it a timeslice.  If it still ready and the highest priority
at the end of the time slice, it gets another "kick at the can" until it is
either "not ready" or another thread of higher priority is
"ready". 
Multiple ready threads of equal priority are dispatched in a round robin
fashion of 1 timeslice each.

 The above describes the behaviour with PRIORITY=ABSOLUTE specified, and is
also affected by the second (y) value of TIMESLICE=x,y. 


 The picture changes quite a bit with PRIORITY=DYNAMIC. With this
specified, the scheduler dynamicly changes the internal priority of a
thread based on it's behaviour. The types of "behaviour" it looks at are: 
 Foreground process
 Owning the keyboard
 Voluntary yield
 I/O activity (I/O completion)
 VDM simulated interrupt
 Starvation 
 
 When the behaviour of a thread is mapped against the above, the scheduler
will increase the priority of the thread. 
 Neither Idle nor Time Critical threads are affected by dynamic priority
adjustment. Normal and Fixed High threads will never be "boosted" into the
TC range. 
 Starvation is affected by the MAXWAIT config parameter. It is the
timeframe that a thread must be ready, without it's "kick at the can"
before it is considered as "starved".
 The first value (x) on the TIMESLICE parameter also affects this, in that
it controls how long the timeslice of a "boosted" thread should be. In
effect, there can be 2 different "timeslice" lengths, one for
"normal"
(round robin) operation and one for dynamicly "boosted" threads. 
 The following table (lifted from the Warp Debug Handbook) shows the values
used by the scheduler in it's "boosting" for the internal OS/2 dispatcher
priority table:

 -----------------------------------------------------------------
  TCBPriLevel 
   The priority delta which may range from 0x00 to 0x1f. 
  TCBPriClassMod 
   The priority boosts which may be any of the combined values: 
   0x04           Keyboard Boost 
   0x08           CPU Starvation Boost 
   0x10           Device I/O Boost 
   0x20           Foreground Boost 
   0x40           Window Boost 
   0x80           VDM Simulated Interrupt. 
  TCBPriorityMin 
   The minimum allowed priority. Normally 0 but set when priority
   inversion becomes a possibility.
  
 Priority is calculated by forming an index by ORing TCBPriClass and
TCBPriClassMod and reading a constant value from the priority table.
The low byte of this is then further ORed with the TCBPriLevel. 

+----------------------------------------------------------------------+
|Starved         08 --------------------------------------------------+|
|Device I/O      10 -------------------------------------------------+||
|Foreground      20 ------------------------------------------------+|||
|Window          40 -----------------------------------------------+||||
|VDM Interrupt   80 ----------------------------------------------+|||||
|============================================================     ||||||
|Not Keyboard (04)             | Keyboard (04)                    ||||||
|Server  Idle    Regular TC    | Server  Idle    Regular TC       IWFDS|
|0x300,  0x100,  0x200,  0x800,| 0x300,  0x100,  0x200,  0x800,// -----|
|0x62f,  0x100,  0x61f,  0x800,| 0x62f,  0x100,  0x61f,  0x800,// ----S|
|0x72f,  0x100,  0x71f,  0x800,| 0x72f,  0x100,  0x71f,  0x800,// ---D-|
|0x72f,  0x100,  0x71f,  0x800,| 0x72f,  0x100,  0x71f,  0x800,// ---DS|
|0x300,  0x100,  0x300,  0x800,| 0x300,  0x100,  0x400,  0x800,// --F--|
|0x62f,  0x100,  0x61f,  0x800,| 0x62f,  0x100,  0x61f,  0x800,// --F-S|
|0x74f,  0x100,  0x73f,  0x800,| 0x74f,  0x100,  0x73f,  0x800,// --FD-|
|0x74f,  0x100,  0x73f,  0x800,| 0x74f,  0x100,  0x73f,  0x800,// --FDS|
|0x500,  0x100,  0x500,  0x800,| 0x500,  0x100,  0x500,  0x800,// -W---|
|0x62f,  0x100,  0x61f,  0x800,| 0x62f,  0x100,  0x61f,  0x800,// -W--S|
|0x74f,  0x100,  0x73f,  0x800,| 0x74f,  0x100,  0x73f,  0x800,// -W-D-|
|0x74f,  0x100,  0x73f,  0x800,| 0x74f,  0x100,  0x73f,  0x800,// -W-DS|
|0x500,  0x100,  0x500,  0x800,| 0x500,  0x100,  0x500,  0x800,// -WF--|
|0x62f,  0x100,  0x61f,  0x800,| 0x62f,  0x100,  0x61f,  0x800,// -WF-S|
|0x74f,  0x100,  0x73f,  0x800,| 0x74f,  0x100,  0x73f,  0x800,// -WFD-|
|0x74f,  0x100,  0x73f,  0x800,| 0x74f,  0x100,  0x73f,  0x800,// -WFDS|
+----------------------------------------------------------------------+
  
  Notes:   
 VDM Simulated interrupts always result in a value of 0x800 
 Foreground server class is not affected by the keyboard boost. 
 Time-critical class is not affected by any boosts. 
 Idle class is not affected by any boosts. 
 By examining the priority table it is clear that idle class will
  always be pre-empted by any other class. 
 Time-critical class can never be pre-empted by any other class. 
 Time-critical threads can only be pre-empted by other time-critical
  threads with a higher delta. 
 Server and Regular class threads may pre-empt each other depending on
  priority boosts and delta. 
 -----------------------------------------------------------------

 My Notes: 
  I believe the "voluntary yield" is really the "Window
boost" in the 
above. At least that is the behaviour I have seen in dumps and kernel debug
sessions. I need the source code to be sure. 

 You should keep in mind that the dispatcher will "check" the queue of
"ready to run threads" more frequently than just at the end of a timeslice.
For example, a hardware interrupt may make a higher priority "blocked" 
thread become ready. The dispatcher can detect this before the end of a
timeslice, and "preempt" the current thread before the end of it's
"timeslice". 

 There is one more thing worth mentioning here, threads that have entered
"Kmode" are not preemtable. This means that a device driver
"loop" cannot
be preempted - even by a higher priority thread. This is quite distinct
from "hardware interruptable", which is controlled via the STI/CLI CPU
instructions. 


 OK.. This should be enough to set the stage. Feel free to ask questions. I
will answer to the best of my ability. All this is really undocumented, and
subject to changes at any time (even fixpacks). There have not been any 
changes to the basic concepts for quite a while though. 
 If you really feel the need, I can describe how you can "patch" the kernel
to play with the boosting values in the above table. Let me know what
version (and FP level) of the kernel you want to play with.  I have played
with it some, but it does tend to expose some race conditions, especially
in the shell. You are on your own if you mess with it. 
 Hint: LXLite to unpack the kernel and the above table is a direct 
lift from a kernel data area. 


   Denis       

 All opinions are my very own, IBM has no claim upon them
. 
. 
.
 

 



--- Maximus/2 3.01